On Tue, Jun 15, 2021 at 2:40 AM Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > > Elijah Newren via GitGitGadget wrote: > > From: Elijah Newren <newren@xxxxxxxxx> > > > > "zdiff3" is identical to ordinary diff3 except that it allows compaction > > of common lines on the two sides of history at the beginning or end of > > the conflict hunk. > > That was not the main reason behind zdiff3. > > The whole point of zdiff3 was to have something closer to the "merge" > style, even if not technically correct. > > Your proposal is better than diff3 in that respect, but worse than Uwe's > zdiff3. > > If you have this: > > l b r > = = = > A A A > > B b > C C > D D > E E > F F > I i > > merge will output this: > > A > > <<<<<<< l > B > ======= > b > >>>>>>> r > C > D > E > F > <<<<<<< l > I > ======= > i > >>>>>>> r > > This is simple, and useful. > > diff3 will output this: > > A > <<<<<<< l > > B > C > D > E > F > I > ||||||| b > ======= > > b > C > D > E > F > i > >>>>>>> r > > Not very friendly. > > Your zdiff3: > > A > > <<<<<<< l > B > C > D > E > F > I > ||||||| b > ======= > b > C > D > E > F > i > >>>>>>> r > > Just marginally better. Your example here is one where diff3 has no original text in the conflicted region. Empty text is trivially easy to split, making it a somewhat uninteresting testcase for zdiff3. The interesting question is what do you do when that region is non-empty? When it's non-empty, it's not going to match the two sides (i.e. it won't have "C D E F" lines for your example) -- we know that because when the original also matches the two sides, the xdiff code will start with multiple separate conflicts instead of one big one. So, in such a case, do you still decide to split the conflict regions, and if so, how do you split the non-matching original text?
