Sorry about last patch, it had some errors. Here is a better version:

diff --git a/mercurial/context.py b/mercurial/context.py
--- a/mercurial/context.py
+++ b/mercurial/context.py
@@ -377,10 +377,42 @@
 
         r = self._filelog.renamed(self._filenode)
         if r:
-            pl[0] = (r[0], r[1], None)
+            pl[0] = (r[0], r[1], self._repo.file(r[0]))
 
-        return [filectx(self._repo, p, fileid=n, filelog=l)
-                for p, n, l in pl if n != nullid]
+        curr = self.rev()
+        cl = self._repo.changelog
+        mf = self._repo.manifest
+        for i in xrange(len(pl)):
+            path, fnode, fl = pl[i]
+            parentrev = fl.linkrev(fl.rev(fnode))
+            parentnode = cl.node(parentrev)
+            last = None
+            if fnode != nullid and not cl.descendant(parentrev, curr):
+                # duplicate linkrev, explore
+                visit = [curr]
+                seen = set()
+                while visit:
+                    n = visit.pop()
+                    if n <= parentrev or n in seen:
+                        continue
+                    seen.add(n)
+                    cldata = cl.read(parentnode)
+                    if path in cldata[3]:
+                        fn = mf.read(cldata[0]).get(path)
+                        if last is not None and fn != fnode:
+                            continue
+                        if fn == fnode:
+                            last = n
+                    for p in cl.parentrevs(n):
+                        if p != nullrev:
+                            visit.append(p)
+            if last is not None:
+                pl[i] = (path, fnode, fl, last)
+            else:
+                pl[i] = (path, fnode, fl, parentrev)
+
+        return [filectx(self._repo, p, fileid=n, changeid=cln, filelog=l)
+                for p, n, l, cln in pl if n != nullid]
 
     def children(self):
         # hard for renames

The following patch, while still a bit hackish, should make filecontext() do 
the right thing™ when calling parents()

At least for most of the cases.

diff --git a/mercurial/context.py b/mercurial/context.py
--- a/mercurial/context.py
+++ b/mercurial/context.py
@@ -377,10 +377,42 @@
 
         r = self._filelog.renamed(self._filenode)
         if r:
-            pl[0] = (r[0], r[1], None)
+            pl[0] = (r[0], r[1], self._repo.file(r[0]))
 
-        return [filectx(self._repo, p, fileid=n, filelog=l)
-                for p, n, l in pl if n != nullid]
+        curr = self.rev()
+        cl = self._repo.changelog
+        mf = self._repo.manifest
+        for i in xrange(len(pl)):
+            path, n, fl = pl[i]
+            parentrev = fl.linkrev(fl.rev(n))
+            parentnode = cl.node(parentrev)
+            last = None
+            if not cl.descendant(parentrev, curr):
+                # duplicate linkrev, explore
+                visit = [self.rev()]
+                seen = set()
+                while visit:
+                    n = visit.pop(0)
+                    if n <= parentrev or n in seen:
+                        continue
+                    seen.add(n)
+                    cldata = cl.read(parentnode)
+                    if path in cldata[3]:
+                        fn = mf.readdelta(cldata[0]).get(path)
+                        if last is not None and fn != n:
+                            continue
+                        if fn == n:
+                            last = n
+                    for p in cl.parentrevs(n):
+                        if p != nullrev:
+                            visit.append(p)
+            if last is not None:
+                pl[i] = (path, n, fl, last)
+            else:
+                pl[i] = (path, n, fl, parentrev)
+
+        return [filectx(self._repo, p, fileid=n, changeid=cln, filelog=l)
+                for p, n, l, cln in pl if n != nullid]
 
     def children(self):
         # hard for renames

My point is just that, given a situation where we need to merge two revs where 
one is a descendant of the other, can we not safely assume that simply 
choosing the descendant is the right thing to do? After all, given revs a and 
b with chosen common ancestor x, we are looking for a version y that 
incorporates both the changes of a vs x and of b vs x. But in this case, if a 
is a descendant of b, then a already contains the changes of b vs x, so 
choosing it seems the proper thing to do.

I think criss-cross merges usually don't have a unique correct solution.


Here is a (maybe) better picture of the example you used (since I draw
it, I might as well send it)


0 (f0) -- 1 (f1) -------- 3 (f1) ---------------------- 7 (f3)
    \  \       \        /                             /       
     \  \       `------+---------------- 5 (f3) -----' 
      \  \            /                 /             
       \  `------ 2 (f0)               / 
        \               `-------------+------- 6 (f2)
         \                           /        /
          `-------------------- 4 (f2)-------'

The attached file, playground3.rextile, contains a session that provokes a 
situation where hg tries to merge two file revs, one of which is an ancestor 
of the other, but fails to merge because the chosen changelog ancestor lists 
an even older rev. As per mpm's analysis of my last case, there is an 
equidistant other changelog ancestor which would work, but that is not the 
point here. I think Hg should just pick the descendant when merging two files 
where one is a descendant of the another. But maybe there are equally valid 
scenarios where this would not be the right thing to do. Ideas?

I assume that parrens intermezzo didn't change the reasoning behind
msg10924, that the rename part still needs fixing, that mpm never changes
his mind, and that he didn't mean to switch back to testing.

I'm setting this back to chatting.

Switching back to testing. Analysis of parren's report here:

http://markmail.org/message/stzw5mi763o77ckz

Specifically, since this change: http://selenic.com/repo/hg/rev/f153af9580fe

I've just posted a test to the mailing list that fails since these fixes. I 
think it should not.
http://markmail.org/thread/kidaxogur2ns75v4

I've marked issue1561 as superceded by this one and copied nosy.

I'm degrading this to bug, as this is now reduced to a triply-rare case:
duplicate file change with rename being backed out.

But I'm setting this back to chatting as the rename part still needs fixing.

mpm committed a fix in f8ca4035a949 to appear in 1.4. It addresses the
reported cases in the requested way.

The ancestor of a file f in two changesets is no longer simply found in the
filelog: 

If a file with the name f is found in the changesets ancestor then that is
used - no matter if it is related or not. 

If no such file exists then the old method is used - it works in the filelog
and can follow renames but might still show the problematic behaviour
discussed here.

I debugged the problem a little bit.
The reason why the merge is done that way, is that there is an ancestor lookup before 
the actually merging the files, based on their filectx/sha1. As file 'a' has the same 
sha1 in 1 and 3 (in the small example from benoit) the ancestor lookup stops with 
revision 1 as the ancestor (even though  the correct one would be 0). The file in rev 
1 has the content ab, which is the same content as in rev 3. As rev 1 is taken as the 
base content, the merge assumes that the content from 3 must be older then the one 
from 2, as it matches the base content, therefore the content of file 'a' in rev 2 is 
taken (which is a).

I guess the right way to fix this, is to go on with the ancestor search until the 
changeset ancestor is reached and take the 'latest' filectx ancestor.

@tonfa: @ringding: per msgs 7334 and 7324: these describe what we're seeing. 
Identical changes on two different branches are causing the wrong ancestor to be
used for a merge.  The correct ancestor is identified by debugancestor, but
merge --debug shows a different selection.

It's not about trying to correctly interpret the intent of such changes, it's
about providing valid diffs for comparison.

In our case, we have a graphical log that (much crud elided) looks like this:

@  changeset:   8037:89d3a91734bc
|
o    changeset:   8036:01dbf681df64
|\
| o    changeset:   8035:9cd60bb1f301
| |\
| | o    changeset:   8034:630af5a7e4e4
| | |\
| | | o    changeset:   8033:11a3c6757b91
| | | |\
| | | | o  changeset:   8032:b56f236530b5
| | | | |
| | | | | @  changeset:   8031:dad7ab7a3786
| | | | | |

| | | | | o  changeset:   8023:faf256d5c16c

| | | | | o  changeset:   7874:0c7adbb7ddc0
| | | | | |
+---------o  changeset:   7873:f69a0edc8643
| | | | |
o | | | |  changeset:   7872:40a9434212f6
| | | | |  

The files we're concerned with were changed in 8023, 8032, 8037, and 7749 (not
shown below, but in the linear heritage of 7872).  The changes in 8032 and 8031
were identical, and share the same filelog entry.  When attempting to merge 8031
and 8037, debugancestor correctly identifies 7872, but merge chooses 8023 as the
ancestor.  So the diffs for 8031 vs 8023 are empty, even though our files were
changed on this branch, and the diffs for 8037 vs 8023 are completely bogus,
because they're not even on the same branch.

(mostly) @tonfa again: The real problem I have with Mercurial's behavior is that
a completely unrelated change 10000 lines away causes a completely different
merge result -- because when the file text does not match 100% anymore, the
ancestor calculation is correct.

It probably shouldn't be any higher than urgent.

Does anyone else share the opinion that this issue should have the same priority
as issue1295 (critical)?

@tonfa: True, but that doesn't relieve Mercurial of the duty of providing the
correct ancestor to the merge program.

I could also imagine using the changeset date in such a case (later == better).

FWIW, I agree that guessing a merge result is very hard. That is why I keep
insisting that real merges never should be silent. Thus I don't think the
unification of "identical" changes we see here is good; it hides a real "merge".

(With reference to issue1295)

By the way you could use the exact same scenario (two same changes in different
branches, one branch reverts it) and expect the result we have now.
It's very hard to guess the intent from that kind of merge.

More fun with the provided test case: continue with

hg clone -r tip . weirder
hg push weirder
hg push -f weirder
cd weirder
hg merge --debug

Notice how the different toposort of the graph causes another ancestor to be
chosen - and even one of the parents.

For reference, I posted some guesswork and suggested a solution at
http://selenic.com/pipermail/mercurial-devel/2008-October/008324.html

Background: at my company, we have a Subversion repo which I
frequently import into Mercurial via hgpullsvn. A coworker has created
a rather large patch against the svn repo a few weeks ago which I
tried to merge into the current head using hg. To my great surprise,
the merge changeset was empty which led me to the assumption that said
patch had already been merged into the svn repo (bit by bit, I
thought). I was quite baffled when I found out that this was not the
case at all. After investigating this strange case for a few hours, I
found the problem.


svn x-1
    |
    |
  svn x
    |\
    | +-----------\
    |             |
svn x+1    coworker's patch
    |
   ...
    |
    |
   <A>
    |
    |
   <~A>
    |
    |
   ...
    |
svn current (hundreds of revisions later)

The diagram above shows my situation (top is oldest, bottom is
newest). "svn x" is the revision against which my coworker's patch was
made. At one point I had the patch in my working directory and --
being used to Mercurial where it's easy to take back a commit -- I
accidentally committed the patch to the subversion repository (<A>). I
immediately reverted the commit (<~A>) but history cannot be deleted
so the mistake sits there forever.

Now when I try to merge "coworker's patch" and "svn current" in
Mercurial, apparently revision "<A>" is used as the ancestor instead
of "svn x" (that's what merge --debug says; hg debugancestor correctly
reports "svn x"). The end result is that the entire patch is
completely thrown away without any indication that something went
wrong.

Benoit Boissinot was nice enough to produce a testcase:

hg init
echo a > a
hg ci -Am m
echo b >> a
hg ci -Am m
echo a > a
hg ci -Am m
hg up 0
echo b >> a
hg ci -Am m
hg view
hg merge --debug
cat a

You'll get 'a\n' instead of 'a\nb\n'.

Original message: http://selenic.com/pipermail/mercurial/2008-October/021625.html