Re: commiting while the current version is in conflict

Because 

 (0) You are wrong to assume that git does not keep conflict
     information; we can tell if the index is "unmerged" to see
     if you still have unresolved conflicts;

 (1) When the index is unmerged, git-commit will stop even
     before getting to pre-commit hook, so there is no point
     for pre-commit hook to check if the index is unmerged;

 (2) pre-commit hook is a last ditch effort to help ignorant
     users who have already done "git add" without thinking and
     lost the "unmerged" state.  It has to look at and guess at
     the contents for that.

On Fri, Oct 17, 2008 at 01:39, Junio Hamano <junio@twinsun.com> wrote:

That information is already lost at the point when the pre-commit hook is executed. Thus, I more or less had to arrive at the wrong conclusion :)

I realize this, now.

Ignoring the ad hominem attack, I would argue that the two distinct mental concepts of 'I want to commit this in the next commit' and 'I have resolved this conflict' should have two distinct commands. To err is human, which is why rm -i exists. Else, you could just use alias rm='rm -rf'.

Also, within certain boundaries, a tool should adapt to the user, not vice versa.

In my opinion, a pre-add hook which is able to warn the user that something they are about to add is still in conflict would be best. The one piece of feedback I had up to now was very positive.

Richard

"Richard Hartmann" <richih.mailinglist@gmail.com> writes:

Eh, Sorry about that --- I did not mean "ignorant" in that sense. Perhaps replacing the word with "unfortunate" would sound nicer?

Don't you realize that is what the hook is doing already? After making such an error, the definitive information is lost, because the user told the tool that the resolution is done and the file is ready to be committed) by mistake. Even then the hook is trying its best to help the user.

Replace your "rm=rm -rf" sentence with "why undelete exists" and read it again. No, filesystem undelete does not always work (disk block could have been recycled for other files), but it could help you when you did remove a file you wanted to keep by mistake when it can.

As to pre-add hook, I am not enthused, but if somebody sends in a clean patch, I wouldn't be opposed to it at least in principle.

On Fri, Oct 17, 2008 at 10:37, Junio C Hamano <gitster@pobox.com> wrote:

A lot yes. No harm done, apologies for picking the bad interpretation of ignorant.

You misunderstood me, there. I was thinking about the pre-add hook while writing the above. Doing anything at commit time is obviously wrong.

An implicit need for it does apparently exist. Else, the default hook for pre-commit would not need to check for conflicts.

Richard

"Richard Hartmann" <richih.mailinglist@gmail.com> writes:

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

On Fri, Oct 17, 2008 at 11:16, Jakub Narebski <jnareb@gmail.com> wrote:

In that case, you would still need a pre-add hook. The problem is not that people can't mark resolved without adding. It's that they can't add without checking (automatically) if there are no conflicts.

Richard

Jakub Narebski <jnareb@gmail.com> writes:

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.