On Fri, 2009-11-13 at 17:35 +0100, Peter Arrenbrecht wrote:

And with tip (with an added debug line) we get:

ancestor eb935dd1d45b local df8f864b9dcd+ remote 61ecd8ec85ca debug f@df8f864b9dcd+ f@61ecd8ec85ca eb935dd1d45b merging f my f@df8f864b9dcd+ other f@61ecd8ec85ca ancestor f@9a30ef678d2c

This result is actually more correct (though the output is misleading).

- the overall merge ancestor is eb935 (rev 2 above) - on the debug line, we've calculated the file ancestor as eb935 (matching overall) - some idiot (me) decided to store the file level revision in the mergestate - file f is the same in revs 0 and 2 - when we perform the merge, we report the file level ancestor's linkrev changeset in the debug message, which reports a different changeset for the same file contents

First note that revs 2 and 4 are equidistant from the two revs being merged (2 and 1 revs each) and from the root (1 rev), so Mercurial has no good way to distinguish them topologically. It will choose a different one depending on which order the branches appear chronologically.

But why did this work before? Previously Mercurial was using changeset level graphs to merge manifests and (less accurate) file level graphs to merge individual files. While this sometimes gives a better result, it makes the merge as a whole inconsistent: each file's ancestor might lie in a different changeset, resulting in an inconsistent view of "the ancestor changeset" across multiple file merges.