From 4fa5c0591a7b5c71c8ccf71d8401c3337b7867ad Mon Sep 17 00:00:00 2001
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 25 Mar 2013 10:05:13 -0700
Subject: [PATCH] merge-one-file: force content conflict for "both sides added"
case
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 <pathname>".
Move that "always fail for add/add conflict" logic a bit higher to
fix this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-merge-one-file.sh | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index a93d0b4cd33..7e82facf919 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -124,9 +124,10 @@ case "${1:-.}${2:-.}${3:-.}" in
git merge-file "$src1" "$orig" "$src2"
ret=$?
msg=
- if test $ret != 0
+ if test $ret != 0 || test -z "$1"
then
msg='content conflict'
+ ret=1
fi
# Create the working tree file, using "our tree" version from the
@@ -143,10 +144,6 @@ case "${1:-.}${2:-.}${3:-.}" in
msg="${msg}permissions conflict: $5->$6,$7"
ret=1
fi
- if test -z "$1"
- then
- ret=1
- fi
if test $ret != 0
then