{"thread":{"id":"31148","subject":"A possible subtree split bug","startedAt":"2012-07-31T11:21:20Z","lastAt":"2012-08-21T01:48:13Z","messageCount":2,"participants":["Fabien POTENCIER","greened@obbligato.org"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"196225","messageId":"5017BFB0.9070701@gmail.com","threadId":"31148","inReplyTo":null,"subject":"A possible subtree split bug","fromName":"Fabien POTENCIER","fromEmail":"fabien.potencier@gmail.com","sentAt":"2012-07-31T11:21:20Z","receivedAt":"2012-07-31T11:21:20Z","isPatch":false,"sender":{"key":"fabien.potencier@gmail.com","avatar":null},"body":"Hi all,\n\nI've encountered what I think is a bug in the subtree split command \nincluded in contrib.\n\nAccording to the docs:\n\n\"Repeated splits of exactly the same history are\nguaranteed to be identical (ie. to produce the same\ncommit ids).  Because of this, if you add new commits\nand then re-split, the new commits will be attached as\ncommits on top of the history you generated last time...\"\n\nBut unfortunately, that's not always the case.\n\nI've found that if you have a commit that reverts the previous one and \nthen merge a branch where those two commits did not exist, then the next \ntime you split, they won't be present anymore in the split tree.\n\nHere is a simple script that exhibits the issue:\n\n#!/bin/sh\n\ngit init\n\n# create a directory that is going to be split\nmkdir doc\necho \"TEST\" > doc/README\ngit add doc\n# commit A\ngit ci -a -m\"first version\"\n\n# create a branch with a new commit (Z)\ngit co -b test\necho \"TEST\" > doc/README1\ngit add doc/README1\ngit ci -a -m\"added README1\"\ngit co master\n\n# modify the README file (commit B)\necho \"TEST_\" > doc/README\ngit ci -a -m\"second version\"\n\n# revert the change (commit C)\necho \"TEST\" > doc/README\ngit ci -a -m\"revert second version\"\n\n# split\ngit subtree split --prefix=\"doc\" --branch=TARGET\n\n# the log will show the 3 commits as expected (including B and C)\ngit log --oneline TARGET\n\n# merge the test branch\ngit merge -m\"merged test\" test\n\n# re-split\n# deleting the target as the bug prevents the split to happen correctly\ngit branch -D TARGET\ngit subtree split --prefix=\"doc\" --branch=TARGET\n\n# the 2 commits B and C are not in the split anymore\n# the split will only show A then Z which is not the expected result\ngit log --oneline TARGET\n\n\nFabien\n\n-- \nFabien Potencier\nSensio CEO - Symfony lead developer\nsensiolabs.com | symfony.com | fabien.potencier.org\nTél: +33 1 40 99 80 80\n"},{"id":"197485","messageId":"87boi5f21u.fsf@waller.obbligato.org","threadId":"31148","inReplyTo":"5017BFB0.9070701@gmail.com","subject":"Re: A possible subtree split bug","fromName":"","fromEmail":"greened@obbligato.org","sentAt":"2012-08-21T01:48:13Z","receivedAt":"2012-08-21T01:48:13Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Fabien POTENCIER <fabien.potencier@gmail.com> writes:\n\n> According to the docs:\n>\n> \"Repeated splits of exactly the same history are\n> guaranteed to be identical (ie. to produce the same\n> commit ids).  Because of this, if you add new commits\n> and then re-split, the new commits will be attached as\n> commits on top of the history you generated last time...\"\n>\n> But unfortunately, that's not always the case.\n>\n> I've found that if you have a commit that reverts the previous one and\n> then merge a branch where those two commits did not exist, then the\n> next time you split, they won't be present anymore in the split tree.\n\nI'm not entirely sure that they history *should* be the same in the\npresence of a merge.  It's certainly not the same history as when\nthe original split was done so I don't think guarantee holds.\n\n                          -Dave\n"}]}