]> granicus.if.org Git - git/commitdiff
merge-one-file: force content conflict for "both sides added" case
authorJunio C Hamano <gitster@pobox.com>
Mon, 25 Mar 2013 17:05:13 +0000 (10:05 -0700)
committerJunio C Hamano <gitster@pobox.com>
Mon, 25 Mar 2013 20:32:07 +0000 (13:32 -0700)
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

index a93d0b4cd332ff8d5da533d5d8a353ecaf644b09..7e82facf919ad720075690ed51bedf6ccf037774 100755 (executable)
@@ -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