Re: Short "git commit $file" syntax fails in the face of a resolved conflict

From: Nanako Shiraishi <nanako3@lavabit.com>
Date: Jan 23, 2009, 00:45 UTC
Message-ID: <20090123094509.6117@nanako3.lavabit.com>
In-Reply-To: <4978202C.3090703@viscovery.net>

Quoting Johannes Sixt <j.sixt@viscovery.net>:

Show 18 quoted lines

> Please don't top-post.
>
> Nathan Yergler schrieb:
>> Can you elaborate on why doing -i automatically is a bad idea in this
>> case?  [It may really be, I don't pretend to have enough knowledge
>> about git's internals to make a reasoned argument.]  This was
>> unexpected behavior for me as I'd always experienced "git add path &&
>> git commit" and "git commit path" as being equivalent and so I assumed
>> they would work equivalently in this situation.
>
> They are not equivalent. 'git add path && git commit' commits changes to
> path *in addition* to what is already staged before you run this command
> sequence. But 'git commit path' commits *only* changes to path, leaving
> other changes that might be staged uncommitted.
>
> It may become obvious why the latter behavior is unwanted if a merge is in
> progress: The merge left changes (and conflicts) in the index; but with
> 'git commit path' you say that you are not interested in what the index has.

Your explanation is a good answer to Nathan's misunderstanding; "git add path && git commit" and "git commit path" are different.

But Nathan's first sentence is a different matter. I do not think it is coming from the same confusion, and I think the question is a valid one. Your answer does not explain why it is a bad idea to change the behavior of "git commit path" to what "git commit -i path" does during a merge.

The answer of course can be "because it changes the behavior people are very much used to."

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/