{"thread":{"id":"35053","subject":"Bug? Files are losing history after subtree merge","startedAt":"2013-10-02T19:20:17Z","lastAt":"2013-10-02T20:44:17Z","messageCount":5,"participants":["Ralf Thielow","Matthieu Moy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"228520","messageId":"1380741617-14593-1-git-send-email-ralf.thielow@gmail.com","threadId":"35053","inReplyTo":null,"subject":"Bug? Files are losing history after subtree merge","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-10-02T19:20:17Z","receivedAt":"2013-10-02T19:20:17Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"Hi,\n\nrecently I did a merge where a complete repo shall be\nmerged into a specific directory of another repo. I\ntried both the \"subtree\" merge strategy and the option\n\"-Xsubtree=\" of \"recursive\". I noticed that in both\ncases somehow the history of single files were lost\nduring these merges (with history I mean 'git log '\nand 'git log --follow '). I've worked around this\nby merging without 'subtree' and moving the dirs/files\nmanually. In this case the file history was there.\n\nI've added a test case below for that behaviour. It doesn't\ncatch \"-S recursive -Xsubtree=\" but it should show\nthe issue (hopefully:).\n\nRalf\n---\n t/t6029-merge-subtree.sh | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh\nindex 73fc240..e9a97d7 100755\n--- a/t/t6029-merge-subtree.sh\n+++ b/t/t6029-merge-subtree.sh\n@@ -61,6 +61,14 @@ test_expect_success 'initial merge' '\n \ttest_cmp expected actual\n '\n \n+test_expect_failure 'file keeps history after subtree merge' '\n+\tcd ../git-gui &&\n+\tgit log --follow git-gui.sh >../git/expected &&\n+\tcd ../git &&\n+\tgit log --follow git-gui/git-gui.sh >actual &&\n+\ttest_cmp expected actual\n+'\n+\n test_expect_success 'merge update' '\n \tcd ../git-gui &&\n \techo git-gui2 > git-gui.sh &&\n-- \n1.8.4.652.g0d6e0ce\n"},{"id":"228521","messageId":"vpqsiwjlarx.fsf@anie.imag.fr","threadId":"35053","inReplyTo":"1380741617-14593-1-git-send-email-ralf.thielow@gmail.com","subject":"Re: Bug? Files are losing history after subtree merge","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-10-02T19:42:42Z","receivedAt":"2013-10-02T19:42:42Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ralf Thielow writes:\n\n> Hi,\n>\n> recently I did a merge where a complete repo shall be\n> merged into a specific directory of another repo. I\n> tried both the \"subtree\" merge strategy and the option\n> \"-Xsubtree=\" of \"recursive\". I noticed that in both\n> cases somehow the history of single files were lost\n> during these merges (with history I mean 'git log '\n> and 'git log --follow ').\n\nThis is a known bug of \"git log --follow\": it does not follow accross\nsubtree merge. But your history is still there (try gitk on your project\nfor example).\n\nTechnically, a subtree merge is a merge commit in which files are\nrenamed compared to the second parent. --follow does not manage this\ncase.\n\n> diff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh\n> index 73fc240..e9a97d7 100755\n> --- a/t/t6029-merge-subtree.sh\n> +++ b/t/t6029-merge-subtree.sh\n> @@ -61,6 +61,14 @@ test_expect_success 'initial merge' '\n> \ttest_cmp expected actual\n> '\n> \n> +test_expect_failure 'file keeps history after subtree merge' '\n> +\tcd ../git-gui &&\n> +\tgit log --follow git-gui.sh >../git/expected &&\n> +\tcd ../git &&\n> +\tgit log --follow git-gui/git-gui.sh >actual &&\n> +\ttest_cmp expected actual\n> +'\n> +\n\nThat would actually be good to add a failing test to \"document\" the\nfailure.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"228522","messageId":"CAN0XMOJB4wco+O9EYn3swXHG-o7sHvNY6DPbfqtOi2yFAuFiSA@mail.gmail.com","threadId":"35053","inReplyTo":"vpqsiwjlarx.fsf@anie.imag.fr","subject":"Re: Bug? Files are losing history after subtree merge","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-10-02T20:10:05Z","receivedAt":"2013-10-02T20:10:05Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"On Wed, Oct 2, 2013 at 9:42 PM, Matthieu Moy\n wrote:\n> Ralf Thielow writes:\n>\n>> Hi,\n>>\n>> recently I did a merge where a complete repo shall be\n>> merged into a specific directory of another repo. I\n>> tried both the \"subtree\" merge strategy and the option\n>> \"-Xsubtree=\" of \"recursive\". I noticed that in both\n>> cases somehow the history of single files were lost\n>> during these merges (with history I mean 'git log '\n>> and 'git log --follow ').\n>\n> This is a known bug of \"git log --follow\": it does not follow accross\n> subtree merge. But your history is still there (try gitk on your project\n> for example).\n>\n> Technically, a subtree merge is a merge commit in which files are\n> renamed compared to the second parent. --follow does not manage this\n> case.\n>\n\nThanks for explanation.\nI knew the history of the repo is there, but the history of single files\n(and the ability to look at it) is so important that subtree-merges aren't\nan option for us. Such merges are rarely, luckily, but it would be nice\nto get it work.\n\nThanks\n\n>> diff --git a/t/t6029-merge-subtree.sh b/t/t6029-merge-subtree.sh\n>> index 73fc240..e9a97d7 100755\n>> --- a/t/t6029-merge-subtree.sh\n>> +++ b/t/t6029-merge-subtree.sh\n>> @@ -61,6 +61,14 @@ test_expect_success 'initial merge' '\n>> test_cmp expected actual\n>> '\n>>\n>> +test_expect_failure 'file keeps history after subtree merge' '\n>> + cd ../git-gui &&\n>> + git log --follow git-gui.sh >../git/expected &&\n>> + cd ../git &&\n>> + git log --follow git-gui/git-gui.sh >actual &&\n>> + test_cmp expected actual\n>> +'\n>> +\n>\n> That would actually be good to add a failing test to \"document\" the\n> failure.\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"},{"id":"228523","messageId":"vpqy56bjuen.fsf@anie.imag.fr","threadId":"35053","inReplyTo":"CAN0XMO+y3Cwsz5LwbmzHBe31Rf-RwMykynLmvmqUsxY8f+1dsQ@mail.gmail.com","subject":"Re: Bug? Files are losing history after subtree merge","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2013-10-02T20:21:36Z","receivedAt":"2013-10-02T20:21:36Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Ralf Thielow writes:\n\n> Thanks for explanation.\n> I knew the history of the repo is there, but the history of single files\n> (and the ability to look at it)\n\nThere is no such thing as \"single file history\" in Git. Git knows about\nthe history of the project, and knows which files were there at each\ncommit. Then, some commands can walk through history following the\nhistory of a file. \"git blame\" is very good at it, and should work with\nsubtree merges. \"git log --follow\" is a quick hack that nobody bothered\nto fix up to now (sadly).\n\nYou can use workarounds like\n\n git log -- '*git-gui.sh'\n\n(from the toplevel), to view each commit that touched a file whose name\nends with git-gui.sh. It won't follow actual renames, and may show false\npositive if you have several files with the same basename. But it may\nhelp.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"228524","messageId":"CAN0XMOJqmia4uTvOTBk75FcidD2hn6NbWf6a5R5GXPk1iDz4gQ@mail.gmail.com","threadId":"35053","inReplyTo":"vpqy56bjuen.fsf@anie.imag.fr","subject":"Re: Bug? Files are losing history after subtree merge","fromName":"Ralf Thielow","fromEmail":"ralf.thielow@gmail.com","sentAt":"2013-10-02T20:44:17Z","receivedAt":"2013-10-02T20:44:17Z","isPatch":false,"sender":{"key":"ralf.thielow@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1275832?v=4"},"body":"On Wed, Oct 2, 2013 at 10:21 PM, Matthieu Moy\n wrote:\n> Ralf Thielow writes:\n>\n>> Thanks for explanation.\n>> I knew the history of the repo is there, but the history of single files\n>> (and the ability to look at it)\n>\n> There is no such thing as \"single file history\" in Git. Git knows about\n> the history of the project, and knows which files were there at each\n> commit. Then, some commands can walk through history following the\n> history of a file. \"git blame\" is very good at it, and should work with\n> subtree merges. \"git log --follow\" is a quick hack that nobody bothered\n> to fix up to now (sadly).\n>\n\nYeah\nFrom a user perspective there is a \"single file history\", isn't it? And in\nthis case the history is gone. At least in the subtree case...\n\n> You can use workarounds like\n>\n> git log -- '*git-gui.sh'\n>\n\n\"My\" users are using gui tools, so there's sadly no chance to change the\ncommands.\nI just wanted to mention the issue but I've worked around it so it's\nno problem anymore.\n\n> (from the toplevel), to view each commit that touched a file whose name\n> ends with git-gui.sh. It won't follow actual renames, and may show false\n> positive if you have several files with the same basename. But it may\n> help.\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\n"}]}