"Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
[An example to reduce
1234<ABCDE|56=AXCYE>789
to
1234A<BCD|56=XCY>E789
elided]
> Note that the common lines, 'A', and 'E' were moved outside the
> conflict. Unlike with the two-way conflicts from the 'merge'
> conflictStyle, the zdiff3 conflict is NOT split into multiple conflict
> regions to allow the common 'C' lines to be shown outside a conflict,
> because zdiff3 shows the base version too and the base version cannot be
> reasonably split.
Another thing that was brought up during the original discussion is
that zdiff3 uses different meaning of "base version" from diff3. In
diff3 output, if you remove everything enclosed in <<< and |||, and
everything enclosed in === and >>>, i.e. 123456789 in the original
example above, you will get "the common ancestor" version, which is
what is shown as the "base". After zdiff3 munges the lines, that is
not the case, 1234A56E789 never appeared in anybody's version. It
is a "starting from the common ancestor version, both sides agreed
to make the same uncontroversial changes, which is already included
in this base version" and zdiff3 inserts the conflict markers and
material unique to each side into it. Being able to recover the
common ancestor version is not always necessary and that is what
makes zdiff3 a plausible solution, but to some workflows and tools
it may matter, so it would be helpful to mention it in the
documentation.
Thanks.
