Hi, On Thu, 28 Dec 2006, Shawn Pearce wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html