whither merge-tree? (was: What's cooking in git.git (Feb 2016, #05; Wed, 17))

From: Jeff King <peff@peff.net>
Date: Feb 22, 2016, 22:12 UTC
Message-ID: <20160222221209.GA18522@sigill.intra.peff.net>
In-Reply-To: <xmqqio1nge5b.fsf@gitster.mtv.corp.google.com>

On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:

Show 8 quoted lines

> * jk/merge-tree-merge-blobs (2016-02-16) 1 commit
>  - merge_blobs: use strbuf instead of manually-sized mmfile_t
> 
>  "git merge-tree" (a throw-away demonstration) did not work very
>  well when merging "both sides added a new file at the same path"
>  case.
> 
>  Undecided; we might be better off deleting it altogether.

What do we want to do with this? I think there are basically three options:

  1. Take the patch you queued above. That's the minimal fix with no
     user-visible changes.

  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 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.

-Peff