From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Stefan Frühwirth" <stefan.fruehwirth@uni-graz.at>, git@vger.kernel.org
Subject: Re: whither merge-tree?
Date: Tue, 23 Feb 2016 01:03:38 -0500 [thread overview]
Message-ID: <20160223060338.GA2912@sigill.intra.peff.net> (raw)
In-Reply-To: <20160223051402.GA23375@sigill.intra.peff.net>
On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:
> 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
next prev parent reply other threads:[~2016-02-23 6:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-17 22:34 What's cooking in git.git (Feb 2016, #05; Wed, 17) Junio C Hamano
2016-02-17 23:25 ` Jeff King
2016-02-18 17:51 ` Junio C Hamano
2016-02-22 22:12 ` whither merge-tree? (was: What's cooking in git.git (Feb 2016, #05; Wed, 17)) Jeff King
2016-02-22 22:45 ` whither merge-tree? Junio C Hamano
2016-02-23 5:02 ` Jeff King
2016-02-23 5:14 ` Jeff King
2016-02-23 6:03 ` Jeff King [this message]
2016-02-23 6:04 ` [PATCH 1/3] merge-one-file: use empty blob for add/add base Jeff King
2016-02-23 6:06 ` [PATCH 2/3] merge-tree: drop generate_common strategy Jeff King
2016-02-23 6:07 ` [PATCH 3/3] xdiff: drop XDL_EMIT_COMMON Jeff King
2016-02-23 6:35 ` whither merge-tree? Junio C Hamano
2016-02-23 7:18 ` Jeff King
2016-02-23 9:49 ` Stefan Frühwirth
2016-02-24 7:28 ` Dennis Kaarsemaker
2016-02-24 7:57 ` Jeff King
2016-02-24 7:58 ` Jeff King
2016-02-23 12:36 ` Johannes Schindelin
2016-02-23 12:41 ` Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160223060338.GA2912@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=stefan.fruehwirth@uni-graz.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).