Re: commiting while the current version is in conflict

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

Jakub Narebski <jnareb@gmail.com> writes:

> From time to time somebody proposes to add a command which is used
> only to say that given conflict got resolved, i.e. yet another
> porcelain "around" git-update-index plumbing (in addition to git-add,
> git-mv and git-rm).  One of problems is how to call it: git-resolve,
> git-resolved, git-mark-resolved?
>
> BTW. while I usually use "git commit -a", when comitting merge commit
> I usually use explicit "git add" together "git commit" (without '-a').

There are three things to keep in mind while thinking about this:

 * "git add" _always_ is to mark "this path now is in a good shape and is
   ready to be committed", whether you are doing a conflict resolution of
   a merge or making a normal commit.

 * you cannot partially commit a merge, as the resulting tree won't be a
   proper merge (i.e. the change from either parents do not describe what
   happened).

 * during a conflicted merge, cleanly merged paths are already staged in
   the index.

Which means that the only paths you would "git add" during a conflicted
merge are the paths you resolved (unless you are creating an evil merge),
and there is no point having a separate "git resolved" -- such a command
will be nothing but an alias to "git add" anyway.

We could add a training wheel mode to "git commit -a" (or "git add -u")
that warns about unmerged paths and asks confirmation, but I suspect that
it would really annoy people who used git for more than 2 weeks if we made
it the default, and on the other hand if it is not the default, it would
not help new people that much.  It is nice to try to help new people from
shooting themselves in the foot, but we need to draw a line somewhere so
that we do not hurt people by being obnoxious.  After all, even these new
people will graduate from the "new" status soon.  My gut feeling is that
helping "oh, I staged the file that I wasn't ready to commit" is on the
other side of that line, especially since the example pre-commit hook
safety is easily available.  If somebody wants to add a pre-add hook that
is run by "git add" Porcelain (but never by "update-index"), that would
add the safety net, too.