Re: whither merge-tree?

Jeff King [off-list ref] 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.?