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

gitster · gitster · commit 4fa5c0591a7b · 2013-03-25T13:32:07.000-07: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 f7d24bb (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 fd66dbf (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 f7d24bb 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>
diff --git 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
