Re: [PATCH 2/2 - RFH/WIP] xdiff-merge: optionally show conflicts in "diff3 -m" style

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, 28 Aug 2008, Junio C Hamano wrote:
>> 
>> Some poeple find it easier to be able to understand what is going on when
>> they can view the common ancestor's version, which is used by "diff3 -m",
>> which shows:
>> 
>>  <<<<<<<
>>  postimage from one side;
>>  |||||||
>>  shared preimage;
>>  =======
>>  postimage of the other side; and
>>  >>>>>>>
> ...
> Wouldn't it be much nicer to make this a bitflag, than an enumeration of 
> different models?
>
> In particular, why would it be wrong to want to be ZEALOUS (possibly 
> _ALNUM) and still want DIFF3 output?
>
> IOW, I don't think these are at all disjoint sets. In fact, I think DIFF3 
> sounds not at all like a "level" to me, but like an output format thing, 
> so it's in a totally different "address space".
>
> Hmm?

I've thought about this a bit more, and I think "diff3 -m" style output
would not make sense for anything more aggressive than XDL_MERGE_EAGER,
because of the way how the merge reduction works.

Suppose a common ancestor (shared preimage) is modified to postimage #1
and #2 (each letter represents one line):

                     #####
    postimage#1: 1234ABCDE789
                    |    /
                    |   /
    preimage:    123456789
                    |   \
    postimage#2: 1234AXYE789
                     ####

XDL_MERGE_MINIMAL and XDL_MERGE_EAGER would:

 (1) find the s/56/ABCDE/ done on one side and s/56/AXYE/ done on the
     other side,

 (2) notice that they touch an overlapping area, and

 (3) mark it as a conflict, "ABCDE vs AXYE".

The difference between the two algorithm is that EAGER drops the hunk if
the postimages match (i.e. both sides modified the same way), while
MINIMAL keeps it.  There is no other operation performed to the hunk.  As
the result, lines marked with "#" in the above picure will be in the RCS
merge style output.  We can sanely say that the part from the preimage
that corresponds to these conflicting changes is "567", which is what
"diff3 -m" style output adds to it.

Now, XDL_MERGE_ZEALOUS postprocesses output XDL_MERGE_EAGER would have
produced, by looking at the differences between the changes two postimages
made.  It notices that both sides start their new contents with "A", and
excludes it from the output (it also excludes "E" for the same reason).
The conflict that used to be "ABCDE vs AXYE" is now "BCD vs XY".

There could even be matching part between two postimages in the middle.
Instead of one side rewriting the shared "56" to "ABCDE" and the other
side to "AXYE", imagine the case where the postimages are "ABCDE" and
"AXCYE", in which case instead of having one conflicted hunk "BCD vs XY",
you would have two conflicting hunks "B vs X" and "D vs Y".

In either case, once you reduce "ABCDE vs AXYE" to "BCD vs XY" (or "ABCDE
vs AXCYE" to "B vs X" and "D vs Y"), there is no part from the preimage
that corresponds to the conflicting change made in both postimages
anymore.  In other words, conflict reduced by ZEALOUS algorithm cannot be
expressed in "diff3 -m" style.

You can still have "diff3 -m" style with MINIMAL or EAGER, but I think MINIMAL
is pointless and using "diff3 -m" style with it is even more so.