Re: whither merge-tree?

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 22, 2016, 22:45 UTC
Message-ID: <xmqqsi0k4b52.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160222221209.GA18522@sigill.intra.peff.net>

Jeff King <peff@peff.net> 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.

Show 7 quoted lines

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