On Fri, Oct 17, 2008 at 01:39, Junio Hamano <junio@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
