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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jan 22, 2009, 09:17 UTC
Message-ID: <49783998.1040400@drmicha.warpmail.net>
In-Reply-To: <c1a864630901211346j4b702fb3tcc5a098ed7e1541d@mail.gmail.com>

Nathan Yergler venit, vidit, dixit 21.01.2009 22:46:

Show 6 quoted lines

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

Because it makes it hard to follow the discussion.

Why shouldn't I?

Fist of all: Please don't top post.

;)

That being said: As Johannes 6t explained (in agreement with git help commit), "git commit path" - which is synonymous with "git commit -o path" is a way of bypassing the index. Think of "Oh wait, I wanted to commit that before I commit what I'm preparing right now.". Now, bypassing the index is no big deal, but bypassing a merge in progress is, because a merge in progress leaves more traces than just the index state (e.g. MERGE_HEAD). That's also why this use case is mentioned explicitly in the man page... In fact, rereading that man page (and testing things to be on the safe side) I have to correct myself: Out of

1) git add path && git commit
2) git commit path
3) git commit -i path

none are equivalent! 1) and 3) are equivalent if and only if "path" is
known to git already: git commit -i does not add new paths.
2) and 3) are equivalent if and only if the index is empty (no changes
staged). The question "When are 1) and 2)" equivalent is left as an
exercise in elementary logic. ;)

Cheers, Michael