Hunks are not computed correctly because the diff3 command is
invoked with arguments in an incorrect order.  The correct order is
the local file first, the base (or "ancestor") second and the other
file third. 

This erroneous behavior has two consequences.  First, the
output of diff3 would change, since it tries to merge chunks according
to maximal matches between the second and first files, and the second
and third files.  Second, ediff, more precisely, `ediff-do-merge',
would consequently try to merge the reverse of the changes from the
base to the other file, leading to a hard to understand merge result in
some cases.

To see the effect on a simple example, consider what
`ediff-merge-with-ancestors` suggests on the three files attached (run
`ediff-merge-with-ancestor' with file A being 'local.txt', file B being
'other.txt' and file C being 'ancestor.txt').

I noticed this problem on a very hairy merge that I can't reproduce here.

Fix to be attached as soon as the bug is created.

-- 
Olivier Certner