Issue 65: When the left and right descendants contain the same change, merge into ancestor

Reported by Unknown User, Jul 1, 2007

(This entry was imported from the savannah tracker, original 
location: https://savannah.nongnu.org/bugs/index.php?20309)

Perhaps this is an artifact of my using meld for all my manual 
merging, however:

Whenever monotone presents me with 3 versions of a file I need to 
merge manually, one scenario occurs with great frequency, and its 
resolution requires absolutely no decision making on my part. This 
is the scenario:

The left descendant and the right descendant both have a change 
which has to go into the ancestor. However, the 2 versions of the 
change are identical in content.

Thus, I mindlessly click through 10s of such hunks. I cannot 
envision a scenario where you wouldn't want to merge something into 
the ancestor that both descendants have identically. After all, if, 
in the course of working on one of the descendants it is decided 
that the hunk is unnecessary, it will be removed, in which case the 
left and right descendants will no longer be "symmetrically 
different" from the ancestor.

My suggestion is that, before monotone offers the 3 versions of the 
file up for merging, all such "symmetrical differences" be 
automatically merged into the ancestor.

I was saying earlier that this may be an artifact of my using meld, 
because only in meld do I have to merge left and right descendant 
into the ancestor (this is a warning issued by monotone before 
running meld). Nonetheless, if the changes introduced in both the 
left and right descendant are identical to one another, IMO they can 
be merged before asking the user to decide on the rest of the 
changes.

monotone version:
-----------------
monotone 0.35 (base revision: 
f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b)
Running on          : Linux 2.6.21.5 #4 SMP Sun Jun 24 13:28:49 EEST 
2007 i686
C++ compiler        : GNU C++ version 4.1.1 (Gentoo 4.1.1-r3)
C++ standard library: GNU libstdc++ version 20060524
Boost version       : 1_33_1
Changes since base revision:
format_version "1"

new_manifest [f95da638a0aa17f7c5979d17a059faf6a46e9670]

old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b]

  Generated from data cached in the distribution;
  further changes may have been made.

Comment 1 by Unknown User, Jul 1, 2007

added attachment meld-screenshot.png

meld-screenshot.png - 136.33 kB

Comment 2 by Unknown User, Jul 1, 2007

Not sure how we would fix this.

The way (file content) merging works is, we attempt to do our 
textual merge, and if the whole files merge cleanly, then great.  
However, even if most of the file merges cleanly (including clean 
merges resulting from identical edits on both sides), even one 
conflicting hunk will cause this stage to fail.

If that stage fails, then we call the user's preferred merge tool, 
and just give it the left/right/ancestor files, and it gets to do 
the whole merge again from scratch, using whatever algorithms, 
heuristics, user interaction, whatever, that it is programmed with.  
It sounds like meld's are sucky when it comes to automatically 
resolving easy hunks so you can find the hard hunks that need your 
attention.  There isn't any way for us to reach into meld's innards 
and tell it to automatically resolve certain hunks for you.

The only way we could do that would be by somehow programmatically 
generating some made-up "ancestor" file, in such a way 
that typical 3-way line-by-line merge tools that happened to use the 
same diff algorithm as monotone would magically find fewer 
conflicts.  This is obviously complex, error prone, and it would 
workaround the limitations of dumb merge tools at the cost of making 
it impossible to create reliable smart merge tools (that really do 
just want to be told the facts on the ground, and then do whatever 
clever thing they know how to do).

Maybe it would be easier to fix meld so it could effectively 
"do the mindless clicking for you", automatically?  I'm 
pretty sure both xxdiff and emacs' ediff-mode get this right, for 
instance.

Comment 3 by Unknown User, Jul 1, 2007

OK. Bottom line: Fix meld. Understood. I wasn't sure whose scope 
this change was in. Thanks for making it clear.

Comment 4 by Stephen Leake, Jun 24, 2012

Status: Invalid