{"thread":{"id":"7564","subject":"Best practices for developing multiple related branches simultaneously","startedAt":"2007-04-08T02:57:29Z","lastAt":"2007-04-08T19:36:46Z","messageCount":3,"participants":["Wink Saville","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"38873","messageId":"d4cf37a60704071957r7bb907eg84180097a4594f43@mail.gmail.com","threadId":"7564","inReplyTo":null,"subject":"Best practices for developing multiple related branches simultaneously","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2007-04-08T02:57:29Z","receivedAt":"2007-04-08T02:57:29Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"Hello,\n\nA couple of questions on how to manage a series of\nhierarchically related branches.\n\nI've created something like this:\n\n----> master\n    \\----> branchA\n         \\----> branchB\n              \\----> branchC\n\nWith the intent to be able to create three separate\npatches that others can make to master and also continue\ndevelopment on all three branches simultaneously.\n\nWhat I'm doing at the moment is to \"git-checkout\"\none of the three branches A, B or C and make changes.\nNote; I don't make changes to master as it represents the\nupstream code and will be pulling from it periodically.\n\nIf the branch is a parent to a child and I want the\nnew changes in the parent to be seen by the children I\nrecursively check out the immediate child do a git-rebase.\n\nFor example:\n\n*) git-checkout branchA\n*) change some files on branchA\n*) git-commit -a\n*) git-checkout branchB\n*) git-rebase branchA\n*) git-checkout branchC\n*) git-rebase branchB\n\nThis seems to work, but is somewhat arduous and I\nwas wondering if there is a better way?\n\nAlso, I'd like to checkout and work on all three branches\nsimultaneously. As is implied above, what I do at the moment is\nuse one repository and to switch branches I use git-checkout, so\nas not to lose work when switching I need to commit before switching.\nSometimes I'd rather not commit as I may just want to look at what was\nin another branch, possibly unrelated to this series. What is a good\nway of handling this situation?\n\nRegards,\n\nWink Saville\n"},{"id":"38874","messageId":"7v7isnbh40.fsf@assigned-by-dhcp.cox.net","threadId":"7564","inReplyTo":"d4cf37a60704071957r7bb907eg84180097a4594f43@mail.gmail.com","subject":"Re: Best practices for developing multiple related branches simultaneously","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-08T04:54:55Z","receivedAt":"2007-04-08T04:54:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Wink Saville\" <wink@saville.com> writes:\n\n> A couple of questions on how to manage a series of\n> hierarchically related branches.\n>\n> I've created something like this:\n>\n> ----> master\n>    \\----> branchA\n>         \\----> branchB\n>              \\----> branchC\n>\n> With the intent to be able to create three separate\n> patches that others can make to master and also continue\n> development on all three branches simultaneously.\n>\n> What I'm doing at the moment is to \"git-checkout\"\n> one of the three branches A, B or C and make changes.\n> Note; I don't make changes to master as it represents the\n> upstream code and will be pulling from it periodically.\n>\n> If the branch is a parent to a child and I want the\n> new changes in the parent to be seen by the children I\n> recursively check out the immediate child do a git-rebase.\n\nThis depends on how you plan to ultimately use the result of\nwork done on the topic branches.  If you are feeding the\ncompleted series as a set of patches to upstream to be applied\n(and eventually contained when you pull into 'master'), this\n\"master is always pristine, topics are constantly rebased on top\nof it\" pattern is a reasonable thing to do.  With a few caveats:\n\n * It is harder to share the topics across multiple people as\n   you are constantly rebasing.\n\n * As you found out, you need to keep track of which ones come\n   directly on top of 'master', which ones are second generation\n   on top of which other branches, etc.\n\nYou do not necessarily have to be constantly rebasing on top of\n'master', though.  You can instead:\n\n - Keep 'master' pristine (as your upstream does not 'pull' from\n   you);\n\n - When you start a topic, try to fork from the branch closest\n   to 'master' (preferrably 'master' itself);\n\n - When there are new changes on 'master' (or topic that is\n   closer to 'master') that affect the work you did on your\n   topic, merge 'master' into the topic, and keep going, never\n   rebasing the topic.  This 'merging from upstream as needed'\n   includes the case where your submission was applied to\n   'master'.\n\nAs you go, when all the work you are done on a topic has been\napplied to 'master', your 'merge from master' would result in\nthe tree of that topic exactly match the tree of 'master'.  At\nthat point you can discard that topic branch.\n\nThe set of changes you have on a topic that have not been\napplied to 'master' can be found using 'git-cherry'.\n\n> Also, I'd like to checkout and work on all three branches\n> simultaneously.\n\nJulian Phillips's git-new-workdir script in contrib/workdir may\nsuit your needs.\n\nHaving said all that, the first advice is to avoid second\ngeneration topic that depends on another topic when possible.\nIs your branchB absolutely need to depend on branchA?\n"},{"id":"38885","messageId":"d4cf37a60704081236yb2b83d6wfe02a10962967ddb@mail.gmail.com","threadId":"7564","inReplyTo":"7v7isnbh40.fsf@assigned-by-dhcp.cox.net","subject":"Re: Best practices for developing multiple related branches simultaneously","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2007-04-08T19:36:46Z","receivedAt":"2007-04-08T19:36:46Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"> > Also, I'd like to checkout and work on all three branches\n> > simultaneously.\n>\n> Julian Phillips's git-new-workdir script in contrib/workdir may\n> suit your needs.\n>\n> Having said all that, the first advice is to avoid second\n> generation topic that depends on another topic when possible.\n> Is your branchB absolutely need to depend on branchA?\n>\n\nBy design they depend upon each other, the other option would\nbe to work on  them in one branch but submit them separately.\nBut I don't know of a good way to segregate them for submission\nas there are modifications to the same files.\n\nActually, even now using separate topics, its not as easy as I'd\nlike if I want to make a \"perfect\" patch. If I want to make an \"imperfect\"\npatch of a particular topic its very easy, for example:\n\n*) git-checkout branchC\n*) git-format-patch -s -n -o patches/branchC branchB\n\nBut this will have all my random commits in the patch, to make a\n\"perfect\" patch for branchC I make another branch, branchC1, off\nof branchB and use git-am to apply the imperfect patch to branchC1.\nand then do another series of commits on branchC1 to make a\nperfect patch by choosing the order I commit the files in the final series\nof commits.\n\nAs you can see my approach to the perfect patch isn't very easy.\nI was looking at stgit as a possible solution, but haven't tried it yet\nand I've never used quilt so I'm not sure its right either.\n\nAnyway, thanks for the help and if you've got any other suggestions\nthey would be much appreciated.\n\nRegards,\n\nWink\n"}]}