# Re: commiting while the current version is in conflict 7 messages from 2008-10-16 to 2008-10-17. Participants: Junio Hamano, Richard Hartmann, Junio C Hamano, Jakub Narebski. Thread: https://gitlist.dev/t/15932 ## Junio Hamano, 2008-10-16 23:39 Subject: Re: commiting while the current version is in conflict Message-ID: <7vy70of6t2.fsf@arte.twinsun.com> URL: https://gitlist.dev/e/7vy70of6t2.fsf%40arte.twinsun.com ``` > Judging from the code in the pre-commit script, git does not > keep conflict information in its metadata cache, but tries to guess > conflicts from the file's contents/ This seems to be a strange > thing to do, imo. What's the reason for this? 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. ``` ## Richard Hartmann, 2008-10-17 07:21 Subject: Re: commiting while the current version is in conflict Message-ID: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com> URL: https://gitlist.dev/e/2d460de70810170021q5daa902er1e6e2fb6633400ec%40mail.gmail.com In-Reply-To: <7vy70of6t2.fsf@arte.twinsun.com> ``` On Fri, Oct 17, 2008 at 01:39, Junio Hamano wrote: > (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; 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 :) > (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; I realize this, now. > (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. 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 ``` ## Junio C Hamano, 2008-10-17 08:37 Subject: Re: commiting while the current version is in conflict Message-ID: <7vwsg7mxb6.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vwsg7mxb6.fsf%40gitster.siamese.dyndns.org In-Reply-To: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com> ``` "Richard Hartmann" writes: >> (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. > > Ignoring the ad hominem attack, I would argue that the two Eh, Sorry about that --- I did not mean "ignorant" in that sense. Perhaps replacing the word with "unfortunate" would sound nicer? > 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. 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. ``` ## Jakub Narebski, 2008-10-17 09:16 Subject: Re: commiting while the current version is in conflict Message-ID: URL: https://gitlist.dev/e/m3d4hzk2du.fsf%40localhost.localdomain In-Reply-To: <2d460de70810170021q5daa902er1e6e2fb6633400ec@mail.gmail.com> ``` "Richard Hartmann" writes: > On Fri, Oct 17, 2008 at 01:39, Junio Hamano wrote: > > (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. > > 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'. >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'). -- Jakub Narebski Poland ShadeHawk on #git ``` ## Richard Hartmann, 2008-10-17 09:32 Subject: Re: commiting while the current version is in conflict Message-ID: <2d460de70810170232o24fcd1d4pd1c7a7503e17b02@mail.gmail.com> URL: https://gitlist.dev/e/2d460de70810170232o24fcd1d4pd1c7a7503e17b02%40mail.gmail.com In-Reply-To: <7vwsg7mxb6.fsf@gitster.siamese.dyndns.org> ``` On Fri, Oct 17, 2008 at 10:37, Junio C Hamano wrote: > Eh, Sorry about that --- I did not mean "ignorant" in that sense. Perhaps > replacing the word with "unfortunate" would sound nicer? A lot yes. No harm done, apologies for picking the bad interpretation of ignorant. > 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. You misunderstood me, there. I was thinking about the pre-add hook while writing the above. Doing anything at commit time is obviously wrong. > 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. 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, 2008-10-17 09:35 Subject: Re: commiting while the current version is in conflict Message-ID: <2d460de70810170235q1c9211c3r1f56067e694b1ac@mail.gmail.com> URL: https://gitlist.dev/e/2d460de70810170235q1c9211c3r1f56067e694b1ac%40mail.gmail.com In-Reply-To: ``` On Fri, Oct 17, 2008 at 11:16, Jakub Narebski wrote: > 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? 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 ``` ## Junio C Hamano, 2008-10-17 09:36 Subject: Re: commiting while the current version is in conflict Message-ID: <7vabd3mulf.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vabd3mulf.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` Jakub Narebski 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. ```