{"thread":{"id":"25091","subject":"git-subtree: bug, and ideas for doc improvements","startedAt":"2010-09-13T11:57:05Z","lastAt":"2010-09-13T12:51:18Z","messageCount":2,"participants":["Yann Dirson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"150587","messageId":"20100913135705.36f8217b@chalon.bertin.fr","threadId":"25091","inReplyTo":null,"subject":"git-subtree: bug, and ideas for doc improvements","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2010-09-13T11:57:05Z","receivedAt":"2010-09-13T11:57:05Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"Hi Avery,\n\nHere are a couple of remarks from trying to work out how to convert\nan imported-with-local-changes kernel to git-subtree.\n\n* When reading the doc, it looks like my use case would require --onto,\n  but although it is documented *when* to we are expected to use that\n  flag, it is not explained *what* it does (which tends to make be both\n  curious and nervous about it ;)\n\n* In addition, describing \"what git subtree is expecting\" without\n  --onto would probably be useful\n\n* If I first run \"split\" without --onto, then \"reset --hard HEAD^\" and\n  rerun the same split with an additional --onto, then:\n  - although a new set of split commits is created, the new branch\n    ref is set to the old one\n  - the split then aborts saying that the new branch ref is not an\n    ancestor\n => this does not happen if I remove the old branch ref first, so it\n does not look tied to the subtree-cache, only to the reachability of\n the old split branch ?  FWIW, old branch (without --onto) is named\n \"linux-2.6\" and new one (with --onto) is \"linux-2.6b\".\n\n* If I run \"split --onto=XXX\" where XXX is as specified in the manpage\n  \"the first revision of the subproject's history that was imported\n  into your project\", then the split history looks exactly the same,\n  appart from:\n  - without --onto, the root of the split branch has no parent\n  - with --onto, the split branch is forked off the specified commit,\n    which is itself not split.  The \"--onto\" name makes that result\n    understandable, but shouldn't the doc tell to use \"the last commit\n    before the subproject's history was imported into your project\"\n    instead ?\n\nBest regards,\n-- \nYann Dirson - Bertin Technologies\n"},{"id":"150589","messageId":"20100913145118.20469cda@chalon.bertin.fr","threadId":"25091","inReplyTo":"20100913135705.36f8217b@chalon.bertin.fr","subject":"Re: git-subtree: bug, and ideas for doc improvements","fromName":"Yann Dirson","fromEmail":"dirson@bertin.fr","sentAt":"2010-09-13T12:51:18Z","receivedAt":"2010-09-13T12:51:18Z","isPatch":false,"sender":{"key":"dirson@bertin.fr","avatar":null},"body":"Well, things finally seem even more complicated: in my case, the tree\nis a bit more particular than what I originally thought:\n\n* I finally understand I read the --onto description wrong.  It could\n  surely be made easier to understand, by telling the user he first\n  has to import the subproject history into the superproject repo\n  first.  Adding an example of this would be of great use too.\n\n* In my case the directory in which the kernel was originally located\n  has since then been renamed, and git-subtree stops exploring the\n  history at the rename commit, assuming the full import occured there.\n\n  Maybe git-subtree can be taught to follow renames, but currently the\n  way to handle that would seem to split in 2 steps:\n  - checkout the revision before the move\n  - split that part of history using the old name (without\n    --rejoin, and with a different --branch name than intended in\n    the end)\n  - checkout the head to be split\n  - split the remaining part, passing --onto the branch name that was\n    passed to --branch in the first run\n\n  However, if I try that, the root of the second split has no parent.\n  I can use a graft and filter-branch - but there is either something\n  else I did not understood incorrectly, or maybe a bug somewhere ?\n\nBest regards,\n-- \nYann Dirson - Bertin Technologies\n"}]}