]> git.ipfire.org Git - thirdparty/git.git/commit
merge-one-file: use empty blob for add/add base
authorJeff King <peff@peff.net>
Tue, 23 Feb 2016 06:04:41 +0000 (01:04 -0500)
committerJunio C Hamano <gitster@pobox.com>
Tue, 23 Feb 2016 06:36:05 +0000 (22:36 -0800)
commit1a92e53ba3614105b7a58a4820f4d33f3cf33a3a
tree096f6cd80e02e7c9774d2335a1e34c0ce2b5f443
parenta2558fb8e1e387b630312311e1d22c95663da5d0
merge-one-file: use empty blob for add/add base

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>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-merge-one-file.sh