Andrew Arnott wrote:
Interesting. I think working in the maintenance branch and merging back into master should work... except when I'm in master when I find the bug and just fix it there without thinking.
That's when you cherry-pick and reset. While having your maintenance branch checked out (after having committed on master), do git cherry-pick master git checkout master git reset --hard HEAD^ Later, when you merge in the maintenance branch again, you get the bugfix you cherry-picked onto maint. On the subject of your workflow though, I think you could definitely benefit from using topic branches (short-lived branches with a few commits to implement one particular feature/bugfix/whatever) so that when you later decide to use a release-branch, you simply merge the topics you want. For preference, bugfix topics should go into your maintenance branch (branch v1.0 in your case), and then the entire maintenance branch should be merged into master, so that master gets all the true and tested bugfixes without you having to verify them twice (assuming clean merges, ofcourse).
The merge and revert idea is interesting. I may try that out in this case since I'm already stuck with lots of commits in master. Regarding why I am porting more than just *some* commits to the maintenance branches, well, these are also stabilization branches before an initial vX.0 release, so in the month or so of stabilization there could be potentially be a great deal of work in master that I decide is worth releasing sooner rather than later.
Why though? Don't you go into feature-freeze when you cut the branch? If you don't, then where do you? -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
