Junio C Hamano [off-list ref] writes:
Jeff King [off-list ref] writes:
quoted
But it would apply to the content that is outside
of the hunk marker; we have changed the concept of what is in the base
and what is in the conflict by shrinking the conflict to its smallest
size.
Hmm, unless you mean by "base" something entirely different from
"what was in the common ancestor version", I do not think I can
agree. The point of diff3 mode is to show how it looked line in the
common ancestor and what the conflicting sides want to change that
common version into; letting the user view three versions to help
him decide what to do by only looking at the part inside conflict
markers.
We show "both sides added, either identically or differently" as
noteworthy events, but the patched code pushes "both sides added
identically" case outside the conflicting hunk, as if what was added
relative to the common ancestor version (in Uwe's case, is it 1-14
that is common, or just 10-14?) is not worth looking at when
considering what the right resolution is. If it is not worth
looking at what was in the original for the conflicting part, why
would we be even using diff3 mode in the first place?
I vaguely recall we did this "clip to eager" as an explicit bugfix
at 83133740d9c8 (xmerge.c: "diff3 -m" style clips merge reduction
level to EAGER or less, 2008-08-29). The list archive around that
time may give us more contexts.
On Wed, Mar 06, 2013 at 01:32:28PM -0800, Junio C Hamano wrote:
quoted
We show "both sides added, either identically or differently" as
noteworthy events, but the patched code pushes "both sides added
identically" case outside the conflicting hunk, as if what was added
relative to the common ancestor version (in Uwe's case, is it 1-14
that is common, or just 10-14?) is not worth looking at when
considering what the right resolution is. If it is not worth
looking at what was in the original for the conflicting part, why
would we be even using diff3 mode in the first place?
I vaguely recall we did this "clip to eager" as an explicit bugfix
at 83133740d9c8 (xmerge.c: "diff3 -m" style clips merge reduction
level to EAGER or less, 2008-08-29). The list archive around that
time may give us more contexts.
Thanks for the pointer. The relevant threads are:
http://article.gmane.org/gmane.comp.version-control.git/94228
and
http://thread.gmane.org/gmane.comp.version-control.git/94339
There is not much discussion beyond what ended up in 8313374; both Linus
and Dscho question whether level and output format are orthogonal, but
seem to accept the explanation you give in the commit message.
Having read that commit and the surrounding thread, I think I stand by
my argument that "zdiff3" is a useful tool to have, as long as the user
understands what the hunks mean. It should never replace diff3, but I
think it makes sense as a separate format.
I was also curious whether it would the diff3/zealous combination would
trigger any weird corner cases. In particular, I wanted to know how the
example you gave in that commit of:
postimage#1: 1234ABCDE789
| /
| /
preimage: 123456789
| \
| \
postimage#2: 1234AXCYE789
would react with diff3 (this is not the original example, but one with
an extra "C" in the middle of postimage#2, which could in theory be
presented as split hunks). However, it seems that we do not do such hunk
splitting at all, neither for diff3 nor for the "merge" representation.
-Peff