Re: [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 23, 2009, 17:01 UTC
- Message-ID
- <7vy6x2vtw3.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <53513726-CE1C-4487-B775-440C6DC93DD8@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
Show 17 quoted lines
> On 23 jan 2009, at 06:21, Junio C Hamano wrote: > >> This makes "git commit paths..." form default to "git commit -i paths" >> semantics only during a merge, restoring the pre-v1.3.0 behaviour. >> The >> codepath to create a non-merge commit is not affected and still >> defaults >> to the "--only" semantics. > > Do you really want to do this? I think this is a pretty large change > that can bite users if they don't know about this -- for example, > because > they forgot that they are in a merge (it happens..). > > FWIW, I'd much rather see a useful error message than this change. If > this change does get in, I think it should be well-documented in the > man pages as well as in the release notes.
As I said already in an earlier message in this thread, this is only a weatherballoon series to help facilitate the discussion, and I am not strongly in favor of this. In fact, if I were, I would have done that long time ago around v1.3.0, because there was a discussion about doing this and the concensus back then was that the command changing the default behaviour between -i and -o was too confusing, even though it may be dwimming better.
The onus is upon those who argued that "commit paths" should default to the --include semantics during a merge resolution in this thread to improve the documentation, if they want this to go forward.