Re: recur status on linux-2.6

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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.