Hi, On Thu, 17 Aug 2006, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Sun, 13 Aug 2006, Junio C Hamano wrote: > > > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. Makes sense. I finally got around to do updated tests, with both git-ls-files --stage and "git diff". It seems like the only issue in the git repository _is_ 10a6653c8. I have not yet had the time to analyze this merge (it is huge!), but I guess recur becomes confused by the timestamps. Ciao, Dscho - 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