Re: [PATCH 3/3] git commit: pathspec without -i/-o implies -i semantics during a merge

[Junio C Hamano <gitster@pobox.com>]

Pieter de Bie <pdebie@ai.rug.nl> writes:

> 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.