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 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>

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