Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Dec 30, 2006, 19:47 UTC
- Message-ID
- <en6fj1$ji5$1@sea.gmane.org>
- In-Reply-To
- <Pine.LNX.4.63.0612301944350.19693@wbgn013.biozentrum.uni-wuerzburg.de>
<opublikowany i wysłany>
Johannes Schindelin wrote:
Show 40 quoted lines
> 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