Re: recur status on linux-2.6

From: Junio C Hamano <junkio@cox.net>
Date: Aug 18, 2006, 04:09 UTC
Message-ID: <7vwt96d6s1.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0608132221030.10541@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 12 quoted lines

> On Sun, 13 Aug 2006, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > I fail to see how this is worse than -recursive...
>> 
>> These are what I got.  ls-files -u output followed by git diff.
>
> I am a little confused here: I thought it would be enough to compare the 
> outputs of "git-ls-files --stage". But that seems wrong.
>
> What are the stages for, again?

I do not offhand remember what git-merge-recursive and git-merge-recur store in stage #1 when they recurse to create a virtual common ancestor. I expected it would contain the blob used as the base for the final file-level three-way merge (i.e. the blob in the virtual common ancestor), and if that is the case, i.e. if the blob matches the second argument for "merge" (from RCS), it should be enough to check that the stages match to verify two implementations do the same thing.

But in practice, stage #1 is not very interesting nor useful after a conflicted merge (git diff --ours and git diff --theirs are more useful, so is git log -p --merge), so it is possible that merge-recursive is leaving the blob from one of the true common ancestors there while using the blob from the virtual common ancestor to produce the final result in the working tree and nobody has noticed. I dunno.