git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 10 of 15 in “Segfault in xdl_merge is back”
  1. Shawn PearceDec 27, 2006
  2. Linus TorvaldsDec 27, 2006
  3. Shawn PearceDec 27, 2006
  4. Johannes SchindelinDec 27, 2006
  5. Alexandre JulliardDec 27, 2006
  6. xdl_merge(): fix a segmentation fault when refining conflictsJohannes Schindelin, Dec 28, 2006
  7. Junio C HamanoDec 28, 2006
  8. Shawn PearceDec 29, 2006
  9. Johannes SchindelinDec 30, 2006
  10. Jakub NarebskiDec 30, 2006
  11. Johannes SchindelinDec 31, 2006
  12. Jakub NarebskiJan 2, 2007
  13. Johannes SchindelinJan 2, 2007
  14. Junio C HamanoJan 2, 2007
  15. Johannes SchindelinJan 2, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.