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. 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. I guess it's not really a stabilization branch in that scenario either, so it's probably my fault trying to walk both sides of a line. I appreciate the thoughts and critique. If anyone else has more thoughts please feel free to throw them in. On Wed, May 28, 2008 at 7:42 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > On 5/28/08, Andrew Arnott <andrewarnott@xxxxxxxxx> wrote: >> At some point, most or all the commits on master since branching off >> v1.0 I want to include in the v1.1 release. > > I think this is perhaps the root of your problem. Normally people > don't merge from master into their bugfix release; they do it the > other way around, making bugfixes in the bugfix branch, and merging > them occasionally into master. > > Or alternatively, they cherry pick just *some* of the changes from > master back into the bugfix release, because presumably there are also > a bunch of non-critical new feature patches sitting in master. > > If you really want to do it the way you described, an easy answer > might be to just merge the entire master into v1.1, then "git revert" > (in v1.1) the patch that changes the version number :) > > Have fun, > > Avery > -- Andrew Arnott -- 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
