GNU bug report logs - #59182
28.1; ediff: Merges with ancestor: Fix computation of hunks and proposed merge

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Olivier Certner <ocert.dev <at> free.fr>
Subject: bug#59182: closed (Re: bug#59182: Proposed fix)
Date: Thu, 17 Nov 2022 09:43:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#59182: 28.1; ediff: Merges with ancestor: Fix computation of hunks and proposed merge

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 59182 <at> debbugs.gnu.org.

-- 
59182: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59182
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Olivier Certner <ocert.dev <at> free.fr>
Cc: 59182-done <at> debbugs.gnu.org
Subject: Re: bug#59182: Proposed fix
Date: Thu, 17 Nov 2022 11:41:53 +0200

> From: Olivier Certner <ocert.dev <at> free.fr>
> Date: Thu, 10 Nov 2022 19:35:28 +0100
> 
> On top of emacs-28 branch (49a14c4375ce4c2c).
> 
> The fix is "minimal", in the sense that it doesn't try to refactor/modify unrelated code.

Thanks, I've now installed this on the master branch, and I'm closing
the bug.

[Message part 3 (message/rfc822, inline)]

From: Olivier Certner <ocert.dev <at> free.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.1;
 ediff: Merges with ancestor: Fix computation of hunks and proposed
 merge
Date: Thu, 10 Nov 2022 19:29:09 +0100

[Message part 4 (text/plain, inline)]

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

[local.txt (text/plain, attachment)]

[ancestor.txt (text/plain, attachment)]

[other.txt (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.