{"thread":{"id":"40945","subject":"git subtree bug produces divergent descendants","startedAt":"2015-12-06T20:41:24Z","lastAt":"2015-12-06T22:18:15Z","messageCount":2,"participants":["David Ware"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"274080","messageId":"CAET=KiVReZMyJmPMMB8eVSqYP9ZF2td-9qdB5KQRTrJSoUt9Bw@mail.gmail.com","threadId":"40945","inReplyTo":null,"subject":"git subtree bug produces divergent descendants","fromName":"David Ware","fromEmail":"davidw@realtimegenomics.com","sentAt":"2015-12-06T20:41:24Z","receivedAt":"2015-12-06T20:41:24Z","isPatch":false,"sender":{"key":"davidw@realtimegenomics.com","avatar":"https://avatars.githubusercontent.com/u/16342344?v=4"},"body":"My group has run into a bug with \"git-subtree split\". Under some\ncircumstances a split created from a descendant of another earlier\nsplit is not a descendant of that earlier split (thus blocking\npushes). We originally noticed this on v1.9.1 but have also checked it\non v2.6.3\n\nWhen scanning the commits to produce the subtree it seems to skip\ncreating a new commit if any of the parent commits have the same tree\nand instead uses that tree in its place. This is fine when the cause\nis a branch that did not cause any changes to the subtree.  However it\ncreates an issue when the cause is both branches ending up with the\nsame tree through identical alterations (or more likely, one of the\nbranches has just a subset of the alterations on the other, such as a\nbranch just containing cherry-picks).\n\nThe attached bash script (makerepo.sh) reproduces the problem. To use\ncreate an empty directory and run the script in it. The resulting\n'master' branch has had the latest commits on the 'branch' branch\nmerged into it, so it follows that a subtree on 'folder/' at 'master'\nshould contain all the commits of a subtree on 'folder/' at 'branch'.\n(These subtrees have been produced at 'subtree_tip' and\n'subtree_branch' respectively.)\n\nThe attached patch (against v2.6.3) fixes the issue for the cases\nwe've encountered, however since we're not particularly familiar with\ngit internals we may not have approached this optimally. We suspect it\ncould be improved to also handle the cases where there are more than 2\nparents.\n\nCheers,\nDave Ware\n\n\nFrom 4bdcd742e5f21d7af57de3e307741efede7d2c6c Mon Sep 17 00:00:00 2001\nFrom: Dave Ware <davidw@netvalue.net.nz>\nDate: Fri, 4 Dec 2015 16:30:03 +1300\nSubject: [PATCH] Fix bug in git-subtree split.\n\nA bug occurs in 'git-subtree split' where a merge is skipped even when\nboth parents act on the subtree, provided the merge results in a tree\nidentical to one of the parents. Fixed by copying the merge if at least\none parent is non-identical, and the non-identical parent is not an\nancestor of the identical parent.\n---\n contrib/subtree/git-subtree.sh | 12 ++++++++++--\n 1 file changed, 10 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh\nindex 9f06571..b837531 100755\n--- a/contrib/subtree/git-subtree.sh\n+++ b/contrib/subtree/git-subtree.sh\n@@ -479,8 +479,16 @@ copy_or_skip()\n \t\t\tp=\"$p -p $parent\"\n \t\tfi\n \tdone\n-\t\n-\tif [ -n \"$identical\" ]; then\n+\n+\tcopycommit=\n+\tif [ -n \"$identical\" ] && [ -n \"$nonidentical\" ]; then\n+\t\textras=$(git rev-list --boundary $identical..$nonidentical)\n+\t\tif [ -n \"$extras\" ]; then\n+\t\t\t# we need to preserve history along the other branch\n+\t\t\tcopycommit=1\n+\t\tfi\n+\tfi\n+\tif [ -n \"$identical\" ] && [ -z \"$copycommit\" ]; then\n \t\techo $identical\n \telse\n \t\tcopy_commit $rev $tree \"$p\" || exit $?\n-- \n1.9.1\n\n"},{"id":"274088","messageId":"CAET=KiXr6nQj13j725FOa0oAbFFdC_zGt-Zyj=EU3+_wOY1A8w@mail.gmail.com","threadId":"40945","inReplyTo":"CAET=KiVReZMyJmPMMB8eVSqYP9ZF2td-9qdB5KQRTrJSoUt9Bw@mail.gmail.com","subject":"Re: git subtree bug produces divergent descendants","fromName":"David Ware","fromEmail":"davidw@realtimegenomics.com","sentAt":"2015-12-06T22:18:15Z","receivedAt":"2015-12-06T22:18:15Z","isPatch":false,"sender":{"key":"davidw@realtimegenomics.com","avatar":"https://avatars.githubusercontent.com/u/16342344?v=4"},"body":"Sorry for the double post, I received a mail blocking notification\nmessage (due to the attached .sh file) and erroneously thought this\nmessage had been blocked from the entire list. My later one includes\nthe test case as part of the attached patch.\n\nCheers,\nDave Ware\n\nOn Mon, Dec 7, 2015 at 9:41 AM, David Ware <davidw@realtimegenomics.com> wrote:\n> My group has run into a bug with \"git-subtree split\". Under some\n> circumstances a split created from a descendant of another earlier\n> split is not a descendant of that earlier split (thus blocking\n> pushes). We originally noticed this on v1.9.1 but have also checked it\n> on v2.6.3\n>\n> When scanning the commits to produce the subtree it seems to skip\n> creating a new commit if any of the parent commits have the same tree\n> and instead uses that tree in its place. This is fine when the cause\n> is a branch that did not cause any changes to the subtree.  However it\n> creates an issue when the cause is both branches ending up with the\n> same tree through identical alterations (or more likely, one of the\n> branches has just a subset of the alterations on the other, such as a\n> branch just containing cherry-picks).\n>\n> The attached bash script (makerepo.sh) reproduces the problem. To use\n> create an empty directory and run the script in it. The resulting\n> 'master' branch has had the latest commits on the 'branch' branch\n> merged into it, so it follows that a subtree on 'folder/' at 'master'\n> should contain all the commits of a subtree on 'folder/' at 'branch'.\n> (These subtrees have been produced at 'subtree_tip' and\n> 'subtree_branch' respectively.)\n>\n> The attached patch (against v2.6.3) fixes the issue for the cases\n> we've encountered, however since we're not particularly familiar with\n> git internals we may not have approached this optimally. We suspect it\n> could be improved to also handle the cases where there are more than 2\n> parents.\n>\n> Cheers,\n> Dave Ware\n"}]}