Menu
▾
▴
#23 merge doesn't handle moved blocks of text well
Helping out a friend - email follows - see attached zip
Here is the example of just moving a function around. T1
is A, t2 is B, t3 is C, and t4 is the Merged result. I chose
B on all merge conflicts, but t4 still doesnt make any
sense.
It would seem that kdiff3 should search for an exact
match for a line before assuming that it is the one that
is next. Perhaps there is a way to tell it. And perhaps if
my function names were more unique it would have
worked better, but the real merges worked just like this.
Logged In: YES
user_id=584435
The zip-file never made it. I think this is a sourceforge-bug. Please
send it per email.
Joachim
example files
Logged In: YES
user_id=11485
sent via email, and second attempt to upload seems to have
worked
Logged In: YES
user_id=584435
Downloading worked now.
I guess you mean the fact that methodc() appears twice in the
output t4.txt. I admit that this is one of the cases where the
automatic selection algorithm makes errors, but this is no bug and
the remedy is not as easy as you suggest.
In your case methodc() has been moved to different places in
t2.txt and t3.txt.
But a generic algorithm can't safely assume this without real
understanding of the text (i.e. understanding of C++). This is too
difficult and out of scope for KDiff3.
Perhaps I should mention this in the documentation: The automatic
algorithms works for most cases but there are a few exceptions.
When the order of lines or blocks of text is changed both branches,
then KDiff3's algorithm that only considers one line at the time, has
its limits and merge errors can occur. (BTW I don't know any
program - commercial or not - that can cope with this under all
circumstances.)
Perhaps KDiff3 could search for moved lines and warn about them,
but since this problem occurs rarely it wouldn't help if there were
warnings in cases that are no problem.
Nevertheless suggestions (or even patches) are welcome.
Cheers,
Joachim