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-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
msg="${msg}permissions conflict: $5->$6,$7"
ret=1
fi
- if test -z "$1"
- then
- ret=1
- fi
if test $ret != 0
then