Re: git-name-rev off-by-one bug

From: Junio C Hamano <junkio@cox.net>
Date: Dec 2, 2005, 08:25 UTC
Message-ID: <7v8xv39a8z.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vslte1y5z.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 9 quoted lines

>  2. merge-one-file leaves unmerged index entries.
>
> Regarding #2, in an earlier message you said something about
> "patch to do that was just broken" which I did not understand; I
> think your patch I am replying to is doing the right thing.  That
> case arm is dealing with a path that exists in "our" branch and
> the working tree blob should be the same as recorded in the
> HEAD, so I did not have to do the unpack-cat-chmod like I did in
> mine.  Am I simply confused?

The only difference is that, from the old tradition, we are supposed to allow the merge to happen in an unchecked-out working tree [*1*]. The version you did and I merged in the master branch breaks that, while the patch I posted keeps that premise.

I can throw in my change on top of what is already commited for now to "fix" this, but do we still care about the "merge should succeed in an unchecked-out working tree" rule, or does it not matter anymore these days?

One thing is that the check with "git diff" to show diff between half-merged and stage2 after a failed merge does not work very well in a sparsely checked out working tree, because the real change is buried among tons of deletes ("diff --diff-filter=UM" helps, though [*2*]).

[Footnote]

*1* ... and that is why we special case a non-existent working tree file as if it is clean with the index. After a merge, you would end up with a sparsely checked-out working tree that contains only the files that were involved in the merge.

*2* Maybe --diff-filter should always include U in the output, because it is rare and when an unmerged entry exists the user would always want to see it.