undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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 f7d24bbefb (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 fd66dbf529 (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 f7d24bbefb 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>
This commit is contained in:
Junio C Hamano 2013-03-25 10:05:13 -07:00
parent d401acf703
commit 4fa5c0591a
1 changed files with 2 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
git-merge-one-file.sh
View File

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