Re: whither merge-tree?
- From
Jeff King <peff@peff.net>
- Date
- Feb 23, 2016, 06:03 UTC
- Message-ID
- <20160223060338.GA2912@sigill.intra.peff.net>
- In-Reply-To
- <20160223051402.GA23375@sigill.intra.peff.net>
On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:
Show 18 quoted lines
> I dug this all the way down to your cb93c19 (merge-one-file: use common > as base, instead of emptiness., 2005-11-09), which states that the goal > is just to get: > > common file contents... > <<<<<< FILENAME > version from our branch... > ====== > version from their branch... > >>>>>> .merge_file_XXXXXX > more common file contents... > > But that seems to be what we produce now. Did all of this simply predate > xdl_merge, and the crappy rcs merge did not bother minimizing the diff? > That certainly seems to be the case in my tests. > > If that is the case, I think we can get rid of the complex > create_virtual_base(), as well.
So here is what I would propose:
[1/3]: merge-one-file: use empty blob for add/add base [2/3]: merge-tree: drop generate_common strategy [3/3]: xdiff: drop XDL_EMIT_COMMON
I briefly wondered if there were any bugs in merge-one-file around this "no newline at end of file" issue. But there shouldn't be. It generates the common file by applying the diff to the first file with "--no-add", which should do the right thing, I think.
I stopped short of dropping the create_virtual_base function in the first patch, for reasons explained there. But if we were to do so, I suspect we could deprecated and eventually drop "apply --no-add", too.
-Peff