Re: commiting while the current version is in conflict

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 17, 2008, 09:36 UTC
Message-ID: <7vabd3mulf.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <m3d4hzk2du.fsf@localhost.localdomain>

Jakub Narebski <jnareb@gmail.com> writes:

Show 8 quoted lines

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