How to merge branches except for one commit

How to merge branches except for one commit

[Andrew Arnott]

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

Re: How to merge branches except for one commit

[Avery Pennarun]

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

Re: How to merge branches except for one commit

[Andrew Arnott]

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

Re: How to merge branches except for one commit

[Junio C Hamano]

"Andrew Arnott" <andrewarnott@gmail.com> writes:

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

In any project, there typically is the 'master' branch that progresses the
(b)leeding edge, and there may be one or more 'maintenance' branches that
forked immediately after you tagged a commit on the 'master' branch.

You however do not necessarily want to _develop_ on these branches.  Their
primary purpose is to give "integration area" for people (the developers
and the customer end users).  If you can plan ahead and carefully decide
where you would first place each of your change, you can use merges more
effectively.

Suppose that you have (for the sake of simplicity of the discussion) two
primary integration branches.  You do not want to add any new features to
the 'maint' branch, and you want to include all the fixes there.  Also you
would want to have all the fixes you give to 'maint' to your 'master'
branch.

When you found a bug, the first thing to think about might be fixing the
bug (obviously), but before making that commit, you need to analyze where
the breakage comes from.  If the root cause of breakage is shared between
'maint' and 'master', then you are better off doing the fix on 'maint' and
then merge the whole 'maint' back to 'master'.

You might not be very confident with your "fix", however, and it is very
valid to be hesitant to make that fix directly on 'maint' branch.  In such
a case, you can fork a topic branch for that single fix off of 'maint',
test it out, and perhaps you may choose to first merge it to 'master' to
see if the fix works for other people and also if it is free of unexpected
side effects for a while, before deciding that the change is safe and is
Ok to merge it to 'maint' [*1*].

In either case (the former gives the fix to 'maint' first and then to
'master'; the latter gives the fix to 'master' first and then to 'maint'
after validating it), the general idea for keep this possible is to do the
fix on a topic branch by forking _the oldest integration branch_ that the
fix could possibly apply to.

Often you would find that there still are breakages in your fix. In such a
case, you can check out the topic branch you worked on the fix, fix the
breakage there, and merge that again to appropriate branches.  As long as
the topic forked off of the right branch, merging it again to 'maint' will
not contaminate 'maint' with unrelated things from 'master'.

You need certain discipline to effectively use merges.  In the "merge"
approach, you have the topics branches keep track of which integration
branches their commits should eventually go.

Once you make a commit on top of something else that you do not want to
pull in, you cannot merge that anymore and you need decide which
individual commits need to be backported after the fact, and this is often
cumbersome.  It is not the end of the world --- it is called "backporting"
and happens often in the real life.  But you can reduce the need for it by
bit of planning.

You can never plan ahead perfectly, so do not be too hard on yourself if
you occasionally screw up.  Cherry-picking from time to time is Ok.  With
practice, you will get used to it.  I juggle 5 integration branches to
maintain git.git itself and it took some practice for me to get
comfortable with the workflow.


[Footnote]

*1* The kernel folks have a policy that their maintenance track 2.6.X.Y
will never have any fix that is not in the mainline.  With such a policy,
you _could_ use this "fork a topic from 'maint' first, merge it into
'master' and after proving it is Ok merge the topic to 'maint'" workflow.
In practice, because different people maintain the mainline and the
maintenance track in that project, this is not done and they do the
equivalent of cherry-pick instead.

Re: How to merge branches except for one commit

[Imran M Yousuf]

>
> You can never plan ahead perfectly, so do not be too hard on yourself if
> you occasionally screw up.  Cherry-picking from time to time is Ok.  With
> practice, you will get used to it.  I juggle 5 integration branches to
> maintain git.git itself and it took some practice for me to get
> comfortable with the workflow.
>

I always wanted to know how you did it, thanks for sharing it :).

Best regards,

-- 
Imran M Yousuf
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557

Re: How to merge branches except for one commit

[Andrew Arnott]

Yes, thanks!

On Wed, May 28, 2008 at 9:38 PM, Imran M Yousuf <imyousuf@gmail.com> wrote:
>>
>> You can never plan ahead perfectly, so do not be too hard on yourself if
>> you occasionally screw up.  Cherry-picking from time to time is Ok.  With
>> practice, you will get used to it.  I juggle 5 integration branches to
>> maintain git.git itself and it took some practice for me to get
>> comfortable with the workflow.
>>
>
> I always wanted to know how you did it, thanks for sharing it :).
>
> Best regards,
>
> --
> Imran M Yousuf
> Email: imran@smartitengineering.com
> Blog: http://imyousuf-tech.blogs.smartitengineering.com/
> Mobile: +880-1711402557
>



-- 
Andrew Arnott

Re: How to merge branches except for one commit

[Andreas Ericsson]

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