Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Dec 30, 2006, 18:53 UTC
Message-ID: <Pine.LNX.4.63.0612301944350.19693@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <20061229041626.GA12072@spearce.org>

Hi,

On Thu, 28 Dec 2006, Shawn Pearce wrote:

Show 21 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > 	Thank you Alexandre! I looked for the bug for quite some time, but 
> > 	was never close to the real culprit.
> 
> Thanks for fixing this!
>  
> > +<<<<<<< orig.txt
> > +=======
> > +Nam et si ambulavero in medio umbrae mortis,
> > +non timebo mala, quoniam TU mecum es:
> > +virga tua et baculus tuus ipsa me consolata sunt.
> > +>>>>>>> new5.txt
> 
> As a side note I lately have noticed that xdl_merge is producing a
> conflict like the above when one branch added the lower half and
> the other branch didn't change anything in the area.
> 
> I haven't spent any time to try to reproduce it, or to see if RCS'
> merge utility would automatically merge the file without producing
> a conflict.  But right now it does seem like xdl_merge is producing
> conflicts when I didn't think it should be.

I thought very long about that problem. It looks like a bug, but it is not. At least in my humble opinion.

If you touched the same spot in two different versions, say you added a fix in one branch, and that fix and a comment in the other one, you might be tempted to automatically resolve that conflict, taking the version with the comment.

But it helps you catch mismerges: If you add a chunk of identical code in the two branches, but with an increment _before_ it in one branch, and _after_ it in the other branch, both should be marked as a conflict.

Of course, you can hit mismerges like the illustrated one _without_ being marked as conflict (e.g. if the chunk of identical code is _not_ added, but only the increments), but we should at least avoid them where possible.

Ciao, Dscho