Jeff King wrote: > On Sun, Jun 13, 2021 at 09:31:55AM -0500, Felipe Contreras wrote: > > > From: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > > > > "zdiff3" is identical to ordinary diff3, only it allows more aggressive > > compaction than diff3. This way the displayed base isn't necessary > > technically correct, but still this mode might help resolving merge > > conflicts between two near identical additions. > > > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> > > --- > > > > I'm re-sending this patch from 2013 because I do think it provides value > > and we might want to make it the default. > > I take it you didn't investigate the segfault I mentioned. I don't know how I was supposed to investigate the few segfaults you mentioned. All you said is that you never tracked the bug. > Try this: > > commit=a5170794372cf1325710a3419473c91ec4af53bf > for style in merge diff3 zdiff3; do > git reset --hard > git checkout $commit^1 > git -c merge.conflictstyle=$style merge $commit^2 > done > > The first two are fine; the zdiff3 one segfaults within the xmerge.c > code. I can reproduct the segfault, and here is a simpler way to reproduce it: (I have a hacked version of diff3 until merge-file learns how to use merge.conflictstyle) cat >b <<EOF A EOF cat >l <<EOF A B C D E F GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG H I EOF cat >r <<EOF A b C D E F GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG H i EOF $git merge-file --diff3 -p l b r -- Felipe Contreras
