[BUG/TEST] show breakage of status for copy+conflict

[BUG/TEST] show breakage of status for copy+conflict

[Will Palmer]

This is more intended to be a demonstration of a bug than an actual
test for inclusion into the library. It probably needs some cleaning
and moving around if it is to be included.

I noticed during a rebase that a conflicted file was not showing up
under the "both changed:" line, and was instead showing up as the
original name of a rename.
This was because the file had conflicts, and so was not in the index
(or at least, not in stage 0, if I have my terminology correct), while
another, very similar (both based on the same template) file had been
added as part of the same change on my side. This has several
interesting effects:
  - the file showed up as the original of a renamed file
  - the file did not show up under the list of files with staged changes
  - the file did not show up under the list of files with unstaged
    changes

Clearly, this is incorrect. It also had the side-effect of causing me to
accidentally add files with conflict-markers, as I thought that perhaps
the merge was simply confused about a similar file having been added.
That is, I thought the file had simple been removed from the index, so
I added it, conflict-markers and all.

the test presented here is based on conflict+copy, a simplification of
the real-world "conflict+addOfSimilarFile" scenario, as it demonstrates
the problem without the need to make up two similar-but-not-copied
files.

in testing, I noticed that "git status" shows the expected results for:
git checkout modify-and-copy && git merge modify-a-file

but shows the incorrect results for:
git checkout modify-a-file && git merge modify-and-copy

I don't really have the time right now to look for exactly what causes
this bug, so I'm hoping that posting a demonstration of it will get
someone else to fix it for me.

Though I don't think this test is appropriate as-is for inclusion, I'm
signing off just to make it clear that it's okay to base other work on
it.

Signed-off-by: Will Palmer <wmpalmer@gmail.com>
---
 t/t7508-status.sh |   56 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)

diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index a72fe3a..4c0a24a 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -7,7 +7,63 @@ test_description='git status'
 
 . ./test-lib.sh
 
+cat >expect << EOF
+# On branch master
+# Unmerged paths:
+#   (use "git add/rm <file>..." as appropriate to mark resolution)
+#
+#	both modified:      A
+#
+# Untracked files:
+#   (use "git add <file>..." to include in what will be committed)
+#
+#	expect
+#	output
+EOF
+
+test_expect_failure "conflict with copy should not trigger rename detection" '
+	cat >A <<- \EOF &&
+		a aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+		b bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
+		c cccccccccccccccccccccccccccccccccccccccccccccccc
+		d dddddddddddddddddddddddddddddddddddddddddddddddd
+		e eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
+		f ffffffffffffffffffffffffffffffffffffffffffffffff
+		g gggggggggggggggggggggggggggggggggggggggggggggggg
+		h hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
+		i iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
+		j jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
+		k kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
+		l llllllllllllllllllllllllllllllllllllllllllllllll
+		m mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
+		n nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
+		o oooooooooooooooooooooooooooooooooooooooooooooooo
+EOF
+	git add A &&
+	git commit -m "add A" &&
+	git tag conflicted-merge-base &&
+	sed -e "/^g /s/.*/g : changed line/" <A >A+ &&
+	cp A B &&
+	mv A+ A &&
+	git add A B &&
+	git commit -m "change and copy A" &&
+	git tag change-copy &&
+	git reset --hard conflicted-merge-base &&
+	sed -e "/^g /s/.*/g : modified row/" <A >A+ &&
+	mv A+ A &&
+	git add A &&
+	git commit -m "change A" &&
+	test_must_fail git merge change-copy &&
+	git status > output &&
+	test_cmp expect output
+'
+
 test_expect_success 'setup' '
+	git reset --hard &&
+	git branch -m merge-test &&
+	git checkout --orphan master &&
+	git rm -f A &&
+	rm expect output &&
 	: >tracked &&
 	: >modified &&
 	mkdir dir1 &&
-- 
1.7.1.703.g42c01

Re: [BUG/TEST] show breakage of status for copy+conflict

[Jonathan Nieder]

Will Palmer wrote:

> I noticed during a rebase that a conflicted file was not showing up
> under the "both changed:" line, and was instead showing up as the
> original name of a rename.
> This was because the file had conflicts, and so was not in the index
> (or at least, not in stage 0, if I have my terminology correct), while
> another, very similar (both based on the same template) file had been
> added as part of the same change on my side.

Hmm, so:

   3
  /
 1 --- 2


1: file A with content A

2: file A with content A',
        B with content A

3: file A with content A''

where the changes A->A' and A->A'' conflict.

And behind the scenes:

There is only one merge-base, so merge_recursive has nothing to
contribute.  It’s all merge_trees()’s bag;

merge_trees() does unpack_trees() before anything else, which could
care less about rename detection;

Then it tries get_renames(), which figures out what happened;

Then process_renames(), which realizes there is nothing to do to fix
this up and reports CONFLICT (content);

And "Automatic merge failed", without any more advice to describe what
happened.

Caller tries "git status".

$ git ls-files --stage --abbrev
100644 aed72d7 1        A
100644 0abac9e 2        A
100644 a5f0d50 3        A
100644 aed72d7 0        B
$ git diff-index --cached HEAD --abbrev
:100644 000000 aed72d7... 0000000... U  A
:000000 100644 0000000... aed72d7... A  B
$ git diff-index -M --cached HEAD --abbrev
:100644 100644 aed72d7... aed72d7... R100       A       B

"git status -s" prints the right output.  So wt_status_collect() seems
to have collected the right information somehow.

> I don't really have the time right now to look for exactly what causes
> this bug, so I'm hoping that posting a demonstration of it will get
> someone else to fix it for me.

No ideas at the moment; sorry.

Jonathan