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

[Michael J Gruber <git@drmicha.warpmail.net>]

Nathan Yergler venit, vidit, dixit 21.01.2009 22:46:
> 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