merge-recursive: conflicting rename case.

This changes the way the case two branches rename the same path
to different paths is handled.  Earlier, the code removed the
original path and added both destinations to the index at
stage0.  This commit changes it to leave the original path at
stage1, and two destination paths at stage2 and stage3,
respectively.

[jc: I am not really sure if this makes much difference in the
real life merge situations.  What should happen when our branch
renames A to B and M to N, while their branch renames A to M?
That is, M remains in our tree as is.]

Signed-off-by: Junio C Hamano <junkio@cox.net>

1 files changed, 37 insertions, 0 deletions

diff --git a/t/t6022-merge-rename.sh b/t/t6022-merge-rename.sh
index 153b9e49f2..1292cafd7f 100755
--- a/t/t6022-merge-rename.sh
+++ b/t/t6022-merge-rename.sh
@@ -161,4 +161,41 @@ test_expect_success 'pull unrenaming branch into renaming one' \
 	}
 '
 
+test_expect_success 'pull conflicting renames' \
+'
+	git reset --hard
+	git show-branch
+	git pull . blue && {
+		echo "BAD: should have conflicted"
+		exit 1
+	}
+	test "$(git ls-files -u A | wc -l)" -eq 1 || {
+		echo "BAD: should have left a stage"
+		exit 1	
+	}
+	test "$(git ls-files -u B | wc -l)" -eq 1 || {
+		echo "BAD: should have left a stage"
+		exit 1	
+	}
+	test "$(git ls-files -u C | wc -l)" -eq 1 || {
+		echo "BAD: should have left a stage"
+		exit 1	
+	}
+	test "$(git ls-files -s N | wc -l)" -eq 1 || {
+		echo "BAD: should have merged N"
+		exit 1	
+	}
+	sed -ne "/^g/{
+	p
+	q
+	}" B | grep red || {
+		echo "BAD: should have listed our change first"
+		exit 1
+	}
+	test "$(git diff white N | wc -l)" -eq 0 || {
+		echo "BAD: should have taken colored branch"
+		exit 1
+	}
+'
+
 test_done