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 00:14:02 -0500 [thread overview]
Message-ID: <20160223051402.GA23375@sigill.intra.peff.net> (raw)
In-Reply-To: <20160223050210.GA17767@sigill.intra.peff.net>
On Tue, Feb 23, 2016 at 12:02:10AM -0500, Jeff King wrote:
> > 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.
>
> I suppose the end result of what merge-tree is trying to do makes sense.
> It's definitely a conflict, but we are interested in showing the minimal
> content-level conflict. But I think xdl_merge() takes care of that for
> us, if we simply feed an empty base. And that is what merge-recursive
> does.
>
> I do see that merge-one-file tries create_virtual_base(), which does
> some magic with diff. But I'm having trouble conceiving of a case where
> that would do something different or useful.
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.
-Peff
next prev parent reply other threads:[~2016-02-23 5:14 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 [this message]
2016-02-23 6:03 ` Jeff King
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=20160223051402.GA23375@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).