{"thread":{"id":"13717","subject":"How to merge branches except for one commit","startedAt":"2008-05-29T02:32:36Z","lastAt":"2008-05-29T15:13:17Z","messageCount":7,"participants":["Andrew Arnott","Avery Pennarun","Junio C Hamano","Imran M Yousuf","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78007","messageId":"216e54900805281932v1397fd30sad91f767175ba95e@mail.gmail.com","threadId":"13717","inReplyTo":null,"subject":"How to merge branches except for one commit","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-05-29T02:32:36Z","receivedAt":"2008-05-29T02:32:36Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"Hi helpful git users!\n\nI have a pattern for work (which may be flawed--feel free to jab it)\nthat leads me to a difficult maintenance story:\n\nWork on master..., tracked source code set to v1.0\nCreate branch v1.0.... tag v1.0.0\nOn master, increment version of library in source code to v2.0\nMore work on master...\nCherry-pick most of the commits on master to the v1.0 branch, leaving\noff the commit that changed master's version number to v2.0\nTag v1.1.\nWork on master continues toward v2.0...\nBranch off v2.0...\n(and the pattern continues, with some commits in master getting\nback-ported to maintenance branches.\n\nAt some point, most or all the commits on master since branching off\nv1.0 I want to include in the v1.1 release. When I want to include\nall the commits from master in the v1.0 branch I just do:\ngit checkout v1.0\ngit merge master\n...and life is good because gitk history makes the merge easy to see\nand individual commits can be easily identified as belonging to both\nmaster and v1.0.\nBut as soon as I branch off v1.0 I want my master branch to start\nbuilding as v2.0, which means the first commit after branching should\nnever be included in the v1.0 branch. As I understand it, that rules\nout ever using \"git merge\". I believe the only option that leaves me\nis cherry picking individual commits, which is a maintenance pain\nbecause each commit then appears as many times as branches it belongs\nto, and it's difficult given just one commit to tell which branches it\nhas been ported to.\n\nAm I doing something wrong, un-knowledgeable of how to properly do\nmerges/cherry-picks, or is this just life as we know it?\n\nThanks.\n--\nAndrew Arnott\n"},{"id":"78008","messageId":"32541b130805281942g2550cad9k7ba530c59e050aa4@mail.gmail.com","threadId":"13717","inReplyTo":"216e54900805281932v1397fd30sad91f767175ba95e@mail.gmail.com","subject":"Re: How to merge branches except for one commit","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-05-29T02:42:16Z","receivedAt":"2008-05-29T02:42:16Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On 5/28/08, Andrew Arnott wrote:\n> At some point, most or all the commits on master since branching off\n> v1.0 I want to include in the v1.1 release.\n\nI think this is perhaps the root of your problem. Normally people\ndon't merge from master into their bugfix release; they do it the\nother way around, making bugfixes in the bugfix branch, and merging\nthem occasionally into master.\n\nOr alternatively, they cherry pick just *some* of the changes from\nmaster back into the bugfix release, because presumably there are also\na bunch of non-critical new feature patches sitting in master.\n\nIf you really want to do it the way you described, an easy answer\nmight be to just merge the entire master into v1.1, then \"git revert\"\n(in v1.1) the patch that changes the version number :)\n\nHave fun,\n\nAvery\n"},{"id":"78010","messageId":"216e54900805282001x299055c3r6cfffcebc61fa955@mail.gmail.com","threadId":"13717","inReplyTo":"32541b130805281942g2550cad9k7ba530c59e050aa4@mail.gmail.com","subject":"Re: How to merge branches except for one commit","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-05-29T03:01:51Z","receivedAt":"2008-05-29T03:01:51Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"Interesting. I think working in the maintenance branch and merging\nback into master should work... except when I'm in master when I find\nthe bug and just fix it there without thinking.\n\nThe merge and revert idea is interesting. I may try that out in this\ncase since I'm already stuck with lots of commits in master.\n\nRegarding why I am porting more than just *some* commits to the\nmaintenance branches, well, these are also stabilization branches\nbefore an initial vX.0 release, so in the month or so of stabilization\nthere could be potentially be a great deal of work in master that I\ndecide is worth releasing sooner rather than later. I guess it's not\nreally a stabilization branch in that scenario either, so it's\nprobably my fault trying to walk both sides of a line.\n\nI appreciate the thoughts and critique. If anyone else has more\nthoughts please feel free to throw them in.\n\nOn Wed, May 28, 2008 at 7:42 PM, Avery Pennarun wrote:\n> On 5/28/08, Andrew Arnott wrote:\n>> At some point, most or all the commits on master since branching off\n>> v1.0 I want to include in the v1.1 release.\n>\n> I think this is perhaps the root of your problem. Normally people\n> don't merge from master into their bugfix release; they do it the\n> other way around, making bugfixes in the bugfix branch, and merging\n> them occasionally into master.\n>\n> Or alternatively, they cherry pick just *some* of the changes from\n> master back into the bugfix release, because presumably there are also\n> a bunch of non-critical new feature patches sitting in master.\n>\n> If you really want to do it the way you described, an easy answer\n> might be to just merge the entire master into v1.1, then \"git revert\"\n> (in v1.1) the patch that changes the version number :)\n>\n> Have fun,\n>\n> Avery\n>\n\n\n\n-- \nAndrew Arnott\n"},{"id":"78013","messageId":"7vhcchrb43.fsf@gitster.siamese.dyndns.org","threadId":"13717","inReplyTo":"216e54900805281932v1397fd30sad91f767175ba95e@mail.gmail.com","subject":"Re: How to merge branches except for one commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-29T04:24:28Z","receivedAt":"2008-05-29T04:24:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Andrew Arnott\" writes:\n\n> Am I doing something wrong, un-knowledgeable of how to properly do\n> merges/cherry-picks, or is this just life as we know it?\n\nIn any project, there typically is the 'master' branch that progresses the\n(b)leeding edge, and there may be one or more 'maintenance' branches that\nforked immediately after you tagged a commit on the 'master' branch.\n\nYou however do not necessarily want to _develop_ on these branches. Their\nprimary purpose is to give \"integration area\" for people (the developers\nand the customer end users). If you can plan ahead and carefully decide\nwhere you would first place each of your change, you can use merges more\neffectively.\n\nSuppose that you have (for the sake of simplicity of the discussion) two\nprimary integration branches. You do not want to add any new features to\nthe 'maint' branch, and you want to include all the fixes there. Also you\nwould want to have all the fixes you give to 'maint' to your 'master'\nbranch.\n\nWhen you found a bug, the first thing to think about might be fixing the\nbug (obviously), but before making that commit, you need to analyze where\nthe breakage comes from. If the root cause of breakage is shared between\n'maint' and 'master', then you are better off doing the fix on 'maint' and\nthen merge the whole 'maint' back to 'master'.\n\nYou might not be very confident with your \"fix\", however, and it is very\nvalid to be hesitant to make that fix directly on 'maint' branch. In such\na case, you can fork a topic branch for that single fix off of 'maint',\ntest it out, and perhaps you may choose to first merge it to 'master' to\nsee if the fix works for other people and also if it is free of unexpected\nside effects for a while, before deciding that the change is safe and is\nOk to merge it to 'maint' [*1*].\n\nIn either case (the former gives the fix to 'maint' first and then to\n'master'; the latter gives the fix to 'master' first and then to 'maint'\nafter validating it), the general idea for keep this possible is to do the\nfix on a topic branch by forking _the oldest integration branch_ that the\nfix could possibly apply to.\n\nOften you would find that there still are breakages in your fix. In such a\ncase, you can check out the topic branch you worked on the fix, fix the\nbreakage there, and merge that again to appropriate branches. As long as\nthe topic forked off of the right branch, merging it again to 'maint' will\nnot contaminate 'maint' with unrelated things from 'master'.\n\nYou need certain discipline to effectively use merges. In the \"merge\"\napproach, you have the topics branches keep track of which integration\nbranches their commits should eventually go.\n\nOnce you make a commit on top of something else that you do not want to\npull in, you cannot merge that anymore and you need decide which\nindividual commits need to be backported after the fact, and this is often\ncumbersome. It is not the end of the world --- it is called \"backporting\"\nand happens often in the real life. But you can reduce the need for it by\nbit of planning.\n\nYou can never plan ahead perfectly, so do not be too hard on yourself if\nyou occasionally screw up. Cherry-picking from time to time is Ok. With\npractice, you will get used to it. I juggle 5 integration branches to\nmaintain git.git itself and it took some practice for me to get\ncomfortable with the workflow.\n\n\n[Footnote]\n\n*1* The kernel folks have a policy that their maintenance track 2.6.X.Y\nwill never have any fix that is not in the mainline. With such a policy,\nyou _could_ use this \"fork a topic from 'maint' first, merge it into\n'master' and after proving it is Ok merge the topic to 'maint'\" workflow.\nIn practice, because different people maintain the mainline and the\nmaintenance track in that project, this is not done and they do the\nequivalent of cherry-pick instead.\n"},{"id":"78016","messageId":"7bfdc29a0805282138kabc5417i4f67ae3995bf238c@mail.gmail.com","threadId":"13717","inReplyTo":"7vhcchrb43.fsf@gitster.siamese.dyndns.org","subject":"Re: How to merge branches except for one commit","fromName":"Imran M Yousuf","fromEmail":"imyousuf@gmail.com","sentAt":"2008-05-29T04:38:21Z","receivedAt":"2008-05-29T04:38:21Z","isPatch":false,"sender":{"key":"imyousuf@gmail.com","avatar":"https://gravatar.com/avatar/fda3c870262849d03c7b9c4d288842e128d6d80769fa7bc2d22731b7597928be?d=mp&s=160"},"body":">\n> You can never plan ahead perfectly, so do not be too hard on yourself if\n> you occasionally screw up. Cherry-picking from time to time is Ok. With\n> practice, you will get used to it. I juggle 5 integration branches to\n> maintain git.git itself and it took some practice for me to get\n> comfortable with the workflow.\n>\n\nI always wanted to know how you did it, thanks for sharing it :).\n\nBest regards,\n\n-- \nImran M Yousuf\nEmail: imran@smartitengineering.com\nBlog: http://imyousuf-tech.blogs.smartitengineering.com/\nMobile: +880-1711402557\n"},{"id":"78018","messageId":"216e54900805282242t1ac249bbv91e4166c72bbcd33@mail.gmail.com","threadId":"13717","inReplyTo":"7bfdc29a0805282138kabc5417i4f67ae3995bf238c@mail.gmail.com","subject":"Re: How to merge branches except for one commit","fromName":"Andrew Arnott","fromEmail":"andrewarnott@gmail.com","sentAt":"2008-05-29T05:42:26Z","receivedAt":"2008-05-29T05:42:26Z","isPatch":false,"sender":{"key":"andrewarnott@gmail.com","avatar":"https://gravatar.com/avatar/e5c2778a1fae32d11e605bca8a9f56f78c43f0b042a5a907471bc4f01cfea4a5?d=mp&s=160"},"body":"Yes, thanks!\n\nOn Wed, May 28, 2008 at 9:38 PM, Imran M Yousuf wrote:\n>>\n>> You can never plan ahead perfectly, so do not be too hard on yourself if\n>> you occasionally screw up. Cherry-picking from time to time is Ok. With\n>> practice, you will get used to it. I juggle 5 integration branches to\n>> maintain git.git itself and it took some practice for me to get\n>> comfortable with the workflow.\n>>\n>\n> I always wanted to know how you did it, thanks for sharing it :).\n>\n> Best regards,\n>\n> --\n> Imran M Yousuf\n> Email: imran@smartitengineering.com\n> Blog: http://imyousuf-tech.blogs.smartitengineering.com/\n> Mobile: +880-1711402557\n>\n\n\n\n-- \nAndrew Arnott\n"},{"id":"78052","messageId":"483EC80D.309@op5.se","threadId":"13717","inReplyTo":"216e54900805282001x299055c3r6cfffcebc61fa955@mail.gmail.com","subject":"Re: How to merge branches except for one commit","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-05-29T15:13:17Z","receivedAt":"2008-05-29T15:13:17Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Andrew Arnott wrote:\n> Interesting. I think working in the maintenance branch and merging\n> back into master should work... except when I'm in master when I find\n> the bug and just fix it there without thinking.\n> \n\nThat's when you cherry-pick and reset. While having your maintenance\nbranch checked out (after having committed on master), do\n\n\tgit cherry-pick master\n\tgit checkout master\n\tgit reset --hard HEAD^\n\nLater, when you merge in the maintenance branch again, you get the\nbugfix you cherry-picked onto maint.\n\nOn the subject of your workflow though, I think you could definitely\nbenefit from using topic branches (short-lived branches with a few\ncommits to implement one particular feature/bugfix/whatever) so that\nwhen you later decide to use a release-branch, you simply merge the\ntopics you want. For preference, bugfix topics should go into your\nmaintenance branch (branch v1.0 in your case), and then the entire\nmaintenance branch should be merged into master, so that master gets\nall the true and tested bugfixes without you having to verify them\ntwice (assuming clean merges, ofcourse).\n\n> The merge and revert idea is interesting. I may try that out in this\n> case since I'm already stuck with lots of commits in master.\n> \n> Regarding why I am porting more than just *some* commits to the\n> maintenance branches, well, these are also stabilization branches\n> before an initial vX.0 release, so in the month or so of stabilization\n> there could be potentially be a great deal of work in master that I\n> decide is worth releasing sooner rather than later.\n\nWhy though? Don't you go into feature-freeze when you cut the branch?\nIf you don't, then where do you?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"}]}