{"thread":{"id":"27376","subject":"Maint-only commits","startedAt":"2011-05-16T21:15:26Z","lastAt":"2011-09-18T19:11:20Z","messageCount":5,"participants":["Stephen Bash","Junio C Hamano","Jay Soffian","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"168020","messageId":"6416457.30612.1305580526325.JavaMail.root@mail.hq.genarts.com","threadId":"27376","inReplyTo":"10397477.30610.1305580263246.JavaMail.root@mail.hq.genarts.com","subject":"Maint-only commits","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2011-05-16T21:15:26Z","receivedAt":"2011-05-16T21:15:26Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"Hi all-\n\nIn my office we've recently run into three separate fixes required on our maintenance branch that should not be included in master (our normal workflow is to make changes on maint, tag, release, and then merge to master). Normally these \"maint only\" fixes are interspersed with commits that should go back into master. In the past the \"maint only\" commits were rare, so I'd carefully use \"merge -s ours\" to avoid including the \"maint only\" changes in master. But now I'm wondering if there's a better process/workflow? Certainly a well crafted alias or custom command makes the user's life easier, but still clutters master with \"extra\" merges.\n\nAny thoughts? Thanks!\n\nStephen\n"},{"id":"168025","messageId":"7vliy6jo8c.fsf@alter.siamese.dyndns.org","threadId":"27376","inReplyTo":"6416457.30612.1305580526325.JavaMail.root@mail.hq.genarts.com","subject":"Re: Maint-only commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-16T22:05:07Z","receivedAt":"2011-05-16T22:05:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Bash writes:\n\n> In my office we've recently run into three separate fixes required on\n> our maintenance branch that should not be included in master (our normal\n> workflow is to make changes on maint, tag, release, and then merge to\n> master). Normally these \"maint only\" fixes are interspersed with\n> commits that should go back into master. In the past the \"maint only\"\n> commits were rare, so I'd carefully use \"merge -s ours\" to avoid\n> including the \"maint only\" changes in master. But now I'm wondering if\n> there's a better process/workflow?\n\nI wonder what these \"maint only\" changes are, and the most importantly, if\nyou know if a change you are about to commit is \"maint only\" material at\nthe time you make it, or if it is something you would notice retroactively\nonly when it is time to prepare merging maint back to master.\n\nAssuming the former, you can use exactly the same discipline you already\nuse to keep your 'maint' free of commits you make on 'master' to add new\nfeatures that shouldn't be in the maintenance track.\n\nLet's think how you are already achieving that.\n\nFirst you examine the change you will make, and decide if it is only meant\nfor master or it should go to both maint and master.\n\nIf the change is meant to go to both maint and master, you would queue to\na branch that can be merged to both maint and master. The simplest\nworkflow to do so is to commit the change directly on maint, later to be\nmerged to master along with other commits on maint. Or you may choose to\nfork a topic branch from maint (or an earlier point on maint) and commit\nthe change on that branch. You would merge the topic branch to 'maint' and\nthen later either merge the whole 'maint' to 'master', or merge the topic\nbranch to 'master'. Alternatively, you may even choose to first merge the\ntopic branch 'master' to make sure it does fix what you wanted to fix and\nthen merge that topic to 'maint' later.\n\nOn the other hand, if a change is only meant for 'master', you either\ncommit directly on 'master' or commit on a topic branch that can be merged\nto 'master' and merge it later to 'master'. But you never merge that\nchange to 'maint'. That means you would not merge the topic branch (if you\nused one) to 'maint', and you would not merge 'master' to 'maint.\n\nHow would you apply the same discipline for \"maint only\" situation?\n\nFirst you examine if the change should only go to 'maint', and if so, you\nwill queue it to a branch that can only be merged to 'maint'. If a change\nshould go both to 'maint' and 'master', you will queue it to a branch that\ncan be merged to both.\n\nNotice that the latter \"branch that can be merged to both\" can _NOT_ be\n'maint', as your 'maint' is contaminated with commits that should not go\nto 'master'. So the first thing to realize is that you no longer are\nallowing yourself to merge 'maint' as a whole to 'master', nor a branch\nthat is forked from 'maint' to 'master'.\n\nWhat follows that observation and discipline are:\n\n - You would keep for-both-maint-and-master, maint, and master branches.\n\n - You treat the for-both-maint-and-master branch the way maint branch in\n projects like git itself is treated, i.e. everything can go to\n master. Commit changes that are meant for both maint and master on this\n branch, either by committing directly on it, or forking a topic from a\n commit on that branch and committing on top of it.\n\n - You merge for-both-maint-and-master into maint and master at\n appropriate times.\n\n - You never merge maint to master, nor merge master to maint.\n\n - You commit changes that should only go to master on master, either by\n committing directly on it, or forking a topic from a commit on that\n branch and committing on top of it.\n\n - You commit changes that should only go to maint on maint, either by\n committing directly on it, or forking a topic from a commit on that\n branch and committing on top of it.\n"},{"id":"168059","messageId":"32603283.31527.1305642038158.JavaMail.root@mail.hq.genarts.com","threadId":"27376","inReplyTo":"7vliy6jo8c.fsf@alter.siamese.dyndns.org","subject":"Re: Maint-only commits","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2011-05-17T14:20:38Z","receivedAt":"2011-05-17T14:20:38Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Junio C Hamano\" \n> Sent: Monday, May 16, 2011 6:05:07 PM\n> Subject: Re: Maint-only commits\n> \n> > In my office we've recently run into three separate fixes required\n> > on our maintenance branch that should not be included in master (our\n> > normal workflow is to make changes on maint, tag, release, and then merge\n> > to master). Normally these \"maint only\" fixes are interspersed with\n> > commits that should go back into master. In the past the \"maint\n> > only\" commits were rare, so I'd carefully use \"merge -s ours\" to avoid\n> > including the \"maint only\" changes in master. But now I'm wondering\n> > if there's a better process/workflow?\n> \n> I wonder what these \"maint only\" changes are, and the most importantly, if\n> you know if a change you are about to commit is \"maint only\" material\n> at the time you make it, or if it is something you would notice\n> retroactively only when it is time to prepare merging maint back to master.\n\nThe three recent cases have all been fixes that, due to refactoring on master, require different changes on the two branches (these specific changes have been non-conflicting in a merge sense, but incorrect in a code sense). All three cases were known ahead of time as \"maint only\", but unfortunately the first one still snuck through the merge process and had to be reverted on master.\n\n> Assuming the former, you can use exactly the same discipline you already\n> use to keep your 'maint' free of commits you make on 'master' to add\n> new features that shouldn't be in the maintenance track.\n\n... ...\n\n> - You would keep for-both-maint-and-master, maint, and master\n> branches.\n> \n> - You treat the for-both-maint-and-master branch the way maint branch\n> in projects like git itself is treated, i.e. everything can go to\n> master. Commit changes that are meant for both maint and master on\n> this branch, either by committing directly on it, or forking a topic from a\n> commit on that branch and committing on top of it.\n> \n> - You merge for-both-maint-and-master into maint and master at\n> appropriate times.\n> \n> - You never merge maint to master, nor merge master to maint.\n> \n> - You commit changes that should only go to master on master, either\n> by committing directly on it, or forking a topic from a commit on that\n> branch and committing on top of it.\n> \n> - You commit changes that should only go to maint on maint, either by\n> committing directly on it, or forking a topic from a commit on that\n> branch and committing on top of it.\n\nThat's certainly a valid approach. I discussed it around the office and got push back on adding additional complexity to our branching model. So I'll document the \"our\" merge approach and perhaps revisit the branching model at the beginning of the next development cycle.\n\nThanks,\nStephen\n"},{"id":"168060","messageId":"BANLkTinAGwJvJuZ_1Y1SK_EhrC0bj2cHHw@mail.gmail.com","threadId":"27376","inReplyTo":"32603283.31527.1305642038158.JavaMail.root@mail.hq.genarts.com","subject":"Re: Maint-only commits","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2011-05-17T15:13:55Z","receivedAt":"2011-05-17T15:13:55Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, May 17, 2011 at 10:20 AM, Stephen Bash wrote:\n> That's certainly a valid approach.  I discussed it around the office and got push back on adding additional complexity to our branching model.  So I'll document the \"our\" merge approach and perhaps revisit the branching model at the beginning of the next development cycle.\n\nAt @work we use something like this. We have three branches:\n\n- trunk (aka master, but it started as a git-svn branch long ago...)\n- release\n- maint\n\nOur maint merges to both trunk and release, via an automated process\nexcept when a conflict requires human intervention.\n\nOccasionally someone will put something on trunk by accident that\nshould've gone to maint. We revert it from trunk, cherry-pick to\nmaint, and let it merge back down.\n\n(Aside, I've found hudson^wjenkins to be great for misc jobs like this\nand prefer it to cron these days for non-sytem-related periodic\nevents.)\n\nj.\n"},{"id":"175735","messageId":"20110918191120.GA6334@nibiru.local","threadId":"27376","inReplyTo":"6416457.30612.1305580526325.JavaMail.root@mail.hq.genarts.com","subject":"Re: Maint-only commits","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2011-09-18T19:11:20Z","receivedAt":"2011-09-18T19:11:20Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Stephen Bash wrote:\n> Hi all-\n> \n> In my office we've recently run into three separate fixes \n> required on our maintenance branch that should not be \n> included in master (our normal workflow is to make changes \n> on maint, tag, release, and then merge to master). Normally \n> these \"maint only\" fixes are interspersed with commits that \n> should go back into master. In the past the \"maint only\" \n> commits were rare, so I'd carefully use \"merge -s ours\" \n> to avoid including the \"maint only\" changes in master. \n> But now I'm wondering if there's a better process/workflow? \n\nOf course, there is: use topic branches and rebase.\n\n\nAssuming you've found a bug in maint, which is also still\nin master.\n\n#1: for off a topic branch (for that bug) from maint\n#2: fix the bug there\n#3: rebase to latest maint (if changed meanwhile) and test carefully\n#4: (ff-)merge your bugfix branch to maint\n#5: rebase bugfix branch to master (maybe incremental, if they\n went too far away from another) and test carefully\n#6: (ff-)merge bugfix branch to master\n#7: drop that topic branch, as you're done now.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"}]}