On Mon, Feb 22, 2016 at 02:45:45PM -0800, Junio C Hamano wrote: > 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. I suppose the end result of what merge-tree is trying to do makes sense. It's definitely a conflict, but we are interested in showing the minimal content-level conflict. But I think xdl_merge() takes care of that for us, if we simply feed an empty base. And that is what merge-recursive does. I do see that merge-one-file tries create_virtual_base(), which does some magic with diff. But I'm having trouble conceiving of a case where that would do something different or useful. > > 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). Yeah, I do not mind doing 2, but I have no idea what else is lurking, and I have very little interest in digging into it. > Let's wait and see how many "please don't"s we hear, perhaps, before > deciding to go 3.? I'm guessing we won't see much either way. Even Stefan, the original reporter, does not seem to actively be using it, but rather relaying a report. We'd probably get more response by doing 2 for now, then adding a deprecation warning to the manpage (and possibly the program itself) for the next release. -Peff -- 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