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

[Jakub Narebski <jnareb@gmail.com>]

<opublikowany i wysłany>

Johannes Schindelin wrote:

> On Thu, 28 Dec 2006, Shawn Pearce wrote:
> 
>> 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.

Perhaps you could make it even more conservating merge conflicts option
(to tighten merge conflicts even more) to xdl_merge, but not used by default
because as it removes accidental conflicts it increases mismerges (falsely
not conflicted).

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git