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: [PATCH 1/3] merge-one-file: use empty blob for add/add base
Date: Tue, 23 Feb 2016 01:04:41 -0500 [thread overview]
Message-ID: <20160223060441.GA3205@sigill.intra.peff.net> (raw)
In-Reply-To: <20160223060338.GA2912@sigill.intra.peff.net>
When we see an add/add conflict on a file, we generate the
conflicted content by doing a 3-way merge with a "virtual"
base consisting of the common lines of the two sides. This
strategy dates back to cb93c19 (merge-one-file: use common
as base, instead of emptiness., 2005-11-09).
Back then, the next step was to call rcs merge to generate
the 3-way conflicts. Using the virtual base produced much
better results, as rcs merge does not attempt to minimize
the hunks. As a result, you'd get a conflict with the
entirety of the files on either side.
Since then, though, we've switched to using git-merge-file,
which uses xdiff's "zealous" merge. This will find the
minimal hunks even with just the simple, empty base.
Let's switch to using that empty base. It's simpler, more
efficient, and reduces our dependencies (we no longer need a
working diff binary). It's also how the merge-recursive
strategy handles this same case.
We can almost get rid of git-sh-setup's create_virtual_base,
but we don't here, for two reasons:
1. The functions in git-sh-setup are part of our public
interface, so it's possible somebody is depending on
it. We'd at least need to deprecate it first.
2. It's also used by mergetool's p4merge driver. It's
unknown whether its 3-way merge is as capable as git's;
if not, then it is benefiting from the function.
Signed-off-by: Jeff King <peff@peff.net>
---
git-merge-one-file.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index cdc02af..424b034 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -120,8 +120,7 @@ case "${1:-.}${2:-.}${3:-.}" in
case "$1" in
'')
echo "Added $4 in both, but differently."
- orig=$(git-unpack-file $2)
- create_virtual_base "$orig" "$src2"
+ orig=$(git-unpack-file e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
;;
*)
echo "Auto-merging $4"
--
2.7.2.645.g4e1306c
next prev parent reply other threads:[~2016-02-23 6:04 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
2016-02-23 6:04 ` Jeff King [this message]
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=20160223060441.GA3205@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).