{"thread":{"id":"24637","subject":"[BUG/TEST] show breakage of status for copy+conflict","startedAt":"2010-08-04T22:19:53Z","lastAt":"2010-08-05T12:55:13Z","messageCount":2,"participants":["Will Palmer","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"147138","messageId":"1280960393-17256-1-git-send-email-wmpalmer@gmail.com","threadId":"24637","inReplyTo":null,"subject":"[BUG/TEST] show breakage of status for copy+conflict","fromName":"Will Palmer","fromEmail":"wmpalmer@gmail.com","sentAt":"2010-08-04T22:19:53Z","receivedAt":"2010-08-04T22:19:53Z","isPatch":false,"sender":{"key":"wmpalmer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/357044?v=4"},"body":"This is more intended to be a demonstration of a bug than an actual\ntest for inclusion into the library. It probably needs some cleaning\nand moving around if it is to be included.\n\nI noticed during a rebase that a conflicted file was not showing up\nunder the \"both changed:\" line, and was instead showing up as the\noriginal name of a rename.\nThis was because the file had conflicts, and so was not in the index\n(or at least, not in stage 0, if I have my terminology correct), while\nanother, very similar (both based on the same template) file had been\nadded as part of the same change on my side. This has several\ninteresting effects:\n - the file showed up as the original of a renamed file\n - the file did not show up under the list of files with staged changes\n - the file did not show up under the list of files with unstaged\n changes\n\nClearly, this is incorrect. It also had the side-effect of causing me to\naccidentally add files with conflict-markers, as I thought that perhaps\nthe merge was simply confused about a similar file having been added.\nThat is, I thought the file had simple been removed from the index, so\nI added it, conflict-markers and all.\n\nthe test presented here is based on conflict+copy, a simplification of\nthe real-world \"conflict+addOfSimilarFile\" scenario, as it demonstrates\nthe problem without the need to make up two similar-but-not-copied\nfiles.\n\nin testing, I noticed that \"git status\" shows the expected results for:\ngit checkout modify-and-copy && git merge modify-a-file\n\nbut shows the incorrect results for:\ngit checkout modify-a-file && git merge modify-and-copy\n\nI don't really have the time right now to look for exactly what causes\nthis bug, so I'm hoping that posting a demonstration of it will get\nsomeone else to fix it for me.\n\nThough I don't think this test is appropriate as-is for inclusion, I'm\nsigning off just to make it clear that it's okay to base other work on\nit.\n\nSigned-off-by: Will Palmer \n---\n t/t7508-status.sh | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 56 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t7508-status.sh b/t/t7508-status.sh\nindex a72fe3a..4c0a24a 100755\n--- a/t/t7508-status.sh\n+++ b/t/t7508-status.sh\n@@ -7,7 +7,63 @@ test_description='git status'\n \n . ./test-lib.sh\n \n+cat >expect << EOF\n+# On branch master\n+# Unmerged paths:\n+# (use \"git add/rm ...\" as appropriate to mark resolution)\n+#\n+#\tboth modified: A\n+#\n+# Untracked files:\n+# (use \"git add ...\" to include in what will be committed)\n+#\n+#\texpect\n+#\toutput\n+EOF\n+\n+test_expect_failure \"conflict with copy should not trigger rename detection\" '\n+\tcat >A <<- \\EOF &&\n+\t\ta aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n+\t\tb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb\n+\t\tc cccccccccccccccccccccccccccccccccccccccccccccccc\n+\t\td dddddddddddddddddddddddddddddddddddddddddddddddd\n+\t\te eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\n+\t\tf ffffffffffffffffffffffffffffffffffffffffffffffff\n+\t\tg gggggggggggggggggggggggggggggggggggggggggggggggg\n+\t\th hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh\n+\t\ti iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii\n+\t\tj jjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj\n+\t\tk kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk\n+\t\tl llllllllllllllllllllllllllllllllllllllllllllllll\n+\t\tm mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm\n+\t\tn nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn\n+\t\to oooooooooooooooooooooooooooooooooooooooooooooooo\n+EOF\n+\tgit add A &&\n+\tgit commit -m \"add A\" &&\n+\tgit tag conflicted-merge-base &&\n+\tsed -e \"/^g /s/.*/g : changed line/\" A+ &&\n+\tcp A B &&\n+\tmv A+ A &&\n+\tgit add A B &&\n+\tgit commit -m \"change and copy A\" &&\n+\tgit tag change-copy &&\n+\tgit reset --hard conflicted-merge-base &&\n+\tsed -e \"/^g /s/.*/g : modified row/\" A+ &&\n+\tmv A+ A &&\n+\tgit add A &&\n+\tgit commit -m \"change A\" &&\n+\ttest_must_fail git merge change-copy &&\n+\tgit status > output &&\n+\ttest_cmp expect output\n+'\n+\n test_expect_success 'setup' '\n+\tgit reset --hard &&\n+\tgit branch -m merge-test &&\n+\tgit checkout --orphan master &&\n+\tgit rm -f A &&\n+\trm expect output &&\n \t: >tracked &&\n \t: >modified &&\n \tmkdir dir1 &&\n-- \n1.7.1.703.g42c01\n"},{"id":"147185","messageId":"20100805125513.GB23334@burratino","threadId":"24637","inReplyTo":"1280960393-17256-1-git-send-email-wmpalmer@gmail.com","subject":"Re: [BUG/TEST] show breakage of status for copy+conflict","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-08-05T12:55:13Z","receivedAt":"2010-08-05T12:55:13Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Will Palmer wrote:\n\n> I noticed during a rebase that a conflicted file was not showing up\n> under the \"both changed:\" line, and was instead showing up as the\n> original name of a rename.\n> This was because the file had conflicts, and so was not in the index\n> (or at least, not in stage 0, if I have my terminology correct), while\n> another, very similar (both based on the same template) file had been\n> added as part of the same change on my side.\n\nHmm, so:\n\n 3\n /\n 1 --- 2\n\n\n1: file A with content A\n\n2: file A with content A',\n B with content A\n\n3: file A with content A''\n\nwhere the changes A->A' and A->A'' conflict.\n\nAnd behind the scenes:\n\nThere is only one merge-base, so merge_recursive has nothing to\ncontribute. It’s all merge_trees()’s bag;\n\nmerge_trees() does unpack_trees() before anything else, which could\ncare less about rename detection;\n\nThen it tries get_renames(), which figures out what happened;\n\nThen process_renames(), which realizes there is nothing to do to fix\nthis up and reports CONFLICT (content);\n\nAnd \"Automatic merge failed\", without any more advice to describe what\nhappened.\n\nCaller tries \"git status\".\n\n$ git ls-files --stage --abbrev\n100644 aed72d7 1 A\n100644 0abac9e 2 A\n100644 a5f0d50 3 A\n100644 aed72d7 0 B\n$ git diff-index --cached HEAD --abbrev\n:100644 000000 aed72d7... 0000000... U A\n:000000 100644 0000000... aed72d7... A B\n$ git diff-index -M --cached HEAD --abbrev\n:100644 100644 aed72d7... aed72d7... R100 A B\n\n\"git status -s\" prints the right output. So wt_status_collect() seems\nto have collected the right information somehow.\n\n> I don't really have the time right now to look for exactly what causes\n> this bug, so I'm hoping that posting a demonstration of it will get\n> someone else to fix it for me.\n\nNo ideas at the moment; sorry.\n\nJonathan\n"}]}