Re: whither merge-tree?

From: Jeff King <peff@peff.net>
Date: Feb 24, 2016, 07:57 UTC
Message-ID: <20160224075702.GA12511@sigill.intra.peff.net>
In-Reply-To: <1456298939.5430.1.camel@kaarsemaker.net>

On Wed, Feb 24, 2016 at 08:28:59AM +0100, Dennis Kaarsemaker wrote:

Show 7 quoted lines

> > So that's a "please don't" leave the code as-is but provide a 
> > (transitional) solution that fixes the reported bug and has the best 
> > chances of not causing any more headaches :)
> 
> I am also actively using it. It's the only way (I know of) of trying to
> preview a merge result without attempting the actual merge, which is
> useful in some of my scripts.

OK. I guess we can live with the series I posted earlier (to simplify the add/add behavior and fix the overflow), and leave it in place.

I _do_ think it's a useful concept, and there isn't something quite like it in git right now. At one point I contemplated teaching unpack-trees to do the content-level merges too, so you could do this via read-tree, but I didn't ever polish it[1]. So I am sympathetic to the goal, and there's not another way to do it as efficiently.

And now I feel like both of you have been warned that the code might be crufty. :)

I'm not sure what we should do about warning others. Since people are using it, I don't want to put a deprecation warning. It's not "this will be removed in the next version" anymore, but "watch out, this might be crufty". I guess that can go in the manpage, but I'm not quite sure how to word it.

-Peff

[1] It looks like my patch has been collecting dust since 2011:

      git://github.com/peff/git.git jk/read-tree-content-merge-wip

    It's been rebased along with all of my other topics since then, but
    otherwise I have no clue if it works or even compiles (it's not part
    of my day-to-day build). Anyone is welcome to use it as a base if
    they want to pursue it.