Re: How to merge branches except for one commit

["Andrew Arnott" <andrewarnott@gmail.com>]

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@gmail.com> wrote:
> On 5/28/08, Andrew Arnott <andrewarnott@gmail.com> 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