delta/git.git/git-merge-one-file.sh, branch v2.37.6

merge-one-file: compute empty blob object ID

2018-05-02T04:59:53+00:00

This script hard-codes the object ID of the empty blob.  To avoid any
problems when changing hashes, compute this value by calling git
hash-object.

Signed-off-by: brian m. carlson 
Signed-off-by: Junio C Hamano

scripts: use "git foo" not "git-foo"

2017-08-07T19:04:45+00:00

We want to make sure that people who copy & paste code would see
fewer instances of "git-foo".  The use of these dashed forms have
been discouraged since v1.6.0 days.

Signed-off-by: Michael Forney 
Signed-off-by: Junio C Hamano

Merge branch 'jk/no-diff-emit-common'

2016-02-26T21:37:14+00:00

"git merge-tree" used to mishandle "both sides added" conflict with
its own "create a fake ancestor file that has the common parts of
what both sides have added and do a 3-way merge" logic; this has
been updated to use the usual "3-way merge with an empty blob as
the fake common ancestor file" approach used in the rest of the
system.

* jk/no-diff-emit-common:
  xdiff: drop XDL_EMIT_COMMON
  merge-tree: drop generate_common strategy
  merge-one-file: use empty blob for add/add base

merge-one-file: use empty blob for add/add base

2016-02-23T06:36:05+00:00

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 
Signed-off-by: Junio C Hamano

merge: detect delete/modechange conflict

2015-10-26T21:49:31+00:00

If one side deletes a file and the other changes its
content, we notice and report a conflict. However, if
instead of changing the content, we change only the mode,
the merge does not notice (and the mode change is silently
dropped).

The trivial index merge notices the problem and correctly
leaves the conflict in the index, but both merge-recursive
and merge-one-file will silently resolve this in favor of
the deletion.  In many cases that is a sane resolution, but
we should be punting to the user whenever there is any
question. So let's detect and treat this as a conflict (in
both strategies).

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

Merge branch 'kb/p4merge'

2013-03-26T20:15:24+00:00

Adjust the order mergetools feeds the files to the p4merge backend
to match the p4 convention.

* kb/p4merge:
  merge-one-file: force content conflict for "both sides added" case
  git-merge-one-file: send "ERROR:" messages to stderr
  git-merge-one-file: style cleanup
  merge-one-file: remove stale comment
  mergetools/p4merge: create a base if none available
  mergetools/p4merge: swap LOCAL and REMOTE

merge-one-file: force content conflict for "both sides added" case

2013-03-25T20:32:07+00:00

Historically, we tried to be lenient to "both sides added, slightly
differently" case and as long as the files can be merged using a
made-up common ancestor cleanly, since f7d24bbefb06 (merge with
/dev/null as base, instead of punting O==empty case, 2005-11-07).

This was later further refined to use a better made-up common file
with fd66dbf5297a (merge-one-file: use empty- or common-base
condintionally in two-stage merge., 2005-11-10), but the spirit has
been the same.

But the original fix in f7d24bbefb06 to avoid punting on "both sides
added" case had a code to unconditionally error out the merge.  When
this triggers, even though the content-level merge can be done
cleanly, we end up not saying "content conflict" in the message, but
still issue the error message, showing "ERROR: in ".

Move that "always fail for add/add conflict" logic a bit higher to
fix this.

Signed-off-by: Junio C Hamano

git-merge-one-file: send "ERROR:" messages to stderr

2013-03-25T17:50:31+00:00

Signed-off-by: Kevin Bracey 
Signed-off-by: Junio C Hamano

git-merge-one-file: style cleanup

2013-03-25T17:50:27+00:00

Update style to match Documentation/CodingGuidelines.

Signed-off-by: Kevin Bracey 
Signed-off-by: Junio C Hamano

merge-one-file: remove stale comment

2013-03-25T17:48:24+00:00

The "funny filename" comment was from b539c5e8fbd3 (git-merge-one:
new merge world order., 2005-12-07) where the removed code just
before that new comment ended with:

        merge "$4" "$orig" "$src2"

(yes, we used to use "merge" program from the RCS suite).  The
comment refers to one of the bad side effect the old code used to
have and warns against such a practice, i.e. it was talking about
the code that no longer existed.

Signed-off-by: Junio C Hamano