How to merge branches except for one commit

Hi helpful git users!

I have a pattern for work (which may be flawed--feel free to jab it)
that leads me to a difficult maintenance story:

Work on master..., tracked source code set to v1.0
Create branch v1.0.... tag v1.0.0
On master, increment version of library in source code to v2.0
More work on master...
Cherry-pick most of the commits on master to the v1.0 branch, leaving
off the commit that changed master's version number to v2.0
Tag v1.1.
Work on master continues toward v2.0...
Branch off v2.0...
(and the pattern continues, with some commits in master getting
back-ported to maintenance branches.

At some point, most or all the commits on master since branching off
v1.0 I want to include in the v1.1 release.  When I want to include
all the commits from master in the v1.0 branch I just do:
git checkout v1.0
git merge master
...and life is good because gitk history makes the merge easy to see
and individual commits can be easily identified as belonging to both
master and v1.0.
But as soon as I branch off v1.0 I want my master branch to start
building as v2.0, which means the first commit after branching should
never be included in the v1.0 branch.  As I understand it, that rules
out ever using "git merge".  I believe the only option that leaves me
is cherry picking individual commits, which is a maintenance pain
because each commit then appears as many times as branches it belongs
to, and it's difficult given just one commit to tell which branches it
has been ported to.

Am I doing something wrong, un-knowledgeable of how to properly do
merges/cherry-picks, or is this just life as we know it?

Thanks.
--
Andrew Arnott

On 5/28/08, Andrew Arnott [off-list ref] 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

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 [off-list ref] wrote:

On 5/28/08, Andrew Arnott [off-list ref] wrote:

quoted

 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

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@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231