Jeff King <peff@xxxxxxxx> writes: > 2. Rip out the weird add/add conflict resolution. This gets rid of the > buggy code, makes merge-tree more like the rest of git, and I think > lets us even drop the EMIT_COMMON stuff from xdiff). That is a nice bonus. git-merge-resolve (rather, git-merge-one-file) attempts the same "resolve add/add by taking the common" thing, but it implements it in quite a different way. > That lets people keep using merge-tree if they have found it useful > over the years. > 3. Drop merge-tree completely. This deletes even more code, and helps > the people in (2) realize that it is utterly unmaintained. :) > > I think at this point I am waffling between (2) and (3). I did (1) in a > hope that I could avoid looking deeper into the code at all, but now > that I have, I do not think (2) would be so bad. I'm happy to work up a > patch, but won't bother if we think that (3) is viable. Yup, between 2 and 3, 2 would certainly be safer, and I agree that it is not too bad (I have this feeling that add-add conflict is not the only funny this code has, though). Let's wait and see how many "please don't"s we hear, perhaps, before deciding to go 3.? -- 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