Jeff King <peff@xxxxxxxx> writes:
> 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.
Without thinking about it too deeply,...
I think the "RCS merge" _could_ show it as "1234A<B=X>C<D=Y>E789"
without losing any information (as it is already discarding what was
in the original in the part that is affected by the conflict,
i.e. "56 was there").
Let's think aloud how "diff3 -m" _should_ split this. The most
straight-forward representation would be "1234<ABCDE|56=AXCYE>789",
that is, where "56" was originally there, one side made it to
"ABCDE" and the other "AXCYE".
You could make it "1234<AB|5=AX><C|=C><DE|6=YE>789", and that is
technically correct (what there were in the shared original for the
conflicted part is 5 and then 6), but the representation pretends
that it knows more than there actually is information, which may be
somewhat misleading. All these three are equally plausible split of
the original "56":
1234<AB|=AX><C|=C><DE|56=YE>789
1234<AB|5=AX><C|=C><DE|6=YE>789
1234<AB|56=AX><C|=C><DE|=YE>789
and picking one over others would be a mere heuristic. All three
are technically correct representations and it is just the matter of
which one is the easiest to understand. So, this is the kind of
"misleading but not incorrect".
In all these cases, the middle part would look like this:
<<<<<<< ours
C
||||||| base
=======
C
>>>>>>> theirs
in order to honor the explicit "I want to view all three versions to
examine the situation" aka "--conflict=diff3" option. We cannot
reduce it to just "C". That will make it "not just misleading but
is actively wrong".
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html