Maint-only commits

Maint-only commits

[Stephen Bash]

Hi all-

In my office we've recently run into three separate fixes required on our maintenance branch that should not be included in master (our normal workflow is to make changes on maint, tag, release, and then merge to master).  Normally these "maint only" fixes are interspersed with commits that should go back into master.  In the past the "maint only" commits were rare, so I'd carefully use "merge -s ours" to avoid including the "maint only" changes in master.  But now I'm wondering if there's a better process/workflow?  Certainly a well crafted alias or custom command makes the user's life easier, but still clutters master with "extra" merges.

Any thoughts?  Thanks!

Stephen

Re: Maint-only commits

[Junio C Hamano]

Stephen Bash <bash@genarts.com> writes:

> In my office we've recently run into three separate fixes required on
> our maintenance branch that should not be included in master (our normal
> workflow is to make changes on maint, tag, release, and then merge to
> master).  Normally these "maint only" fixes are interspersed with
> commits that should go back into master.  In the past the "maint only"
> commits were rare, so I'd carefully use "merge -s ours" to avoid
> including the "maint only" changes in master.  But now I'm wondering if
> there's a better process/workflow?

I wonder what these "maint only" changes are, and the most importantly, if
you know if a change you are about to commit is "maint only" material at
the time you make it, or if it is something you would notice retroactively
only when it is time to prepare merging maint back to master.

Assuming the former, you can use exactly the same discipline you already
use to keep your 'maint' free of commits you make on 'master' to add new
features that shouldn't be in the maintenance track.

Let's think how you are already achieving that.

First you examine the change you will make, and decide if it is only meant
for master or it should go to both maint and master.

If the change is meant to go to both maint and master, you would queue to
a branch that can be merged to both maint and master. The simplest
workflow to do so is to commit the change directly on maint, later to be
merged to master along with other commits on maint. Or you may choose to
fork a topic branch from maint (or an earlier point on maint) and commit
the change on that branch. You would merge the topic branch to 'maint' and
then later either merge the whole 'maint' to 'master', or merge the topic
branch to 'master'.  Alternatively, you may even choose to first merge the
topic branch 'master' to make sure it does fix what you wanted to fix and
then merge that topic to 'maint' later.

On the other hand, if a change is only meant for 'master', you either
commit directly on 'master' or commit on a topic branch that can be merged
to 'master' and merge it later to 'master'. But you never merge that
change to 'maint'. That means you would not merge the topic branch (if you
used one) to 'maint', and you would not merge 'master' to 'maint.

How would you apply the same discipline for "maint only" situation?

First you examine if the change should only go to 'maint', and if so, you
will queue it to a branch that can only be merged to 'maint'. If a change
should go both to 'maint' and 'master', you will queue it to a branch that
can be merged to both.

Notice that the latter "branch that can be merged to both" can _NOT_ be
'maint', as your 'maint' is contaminated with commits that should not go
to 'master'. So the first thing to realize is that you no longer are
allowing yourself to merge 'maint' as a whole to 'master', nor a branch
that is forked from 'maint' to 'master'.

What follows that observation and discipline are:

 - You would keep for-both-maint-and-master, maint, and master branches.

 - You treat the for-both-maint-and-master branch the way maint branch in
   projects like git itself is treated, i.e. everything can go to
   master. Commit changes that are meant for both maint and master on this
   branch, either by committing directly on it, or forking a topic from a
   commit on that branch and committing on top of it.

 - You merge for-both-maint-and-master into maint and master at
   appropriate times.

 - You never merge maint to master, nor merge master to maint.

 - You commit changes that should only go to master on master, either by
   committing directly on it, or forking a topic from a commit on that
   branch and committing on top of it.

 - You commit changes that should only go to maint on maint, either by
   committing directly on it, or forking a topic from a commit on that
   branch and committing on top of it.

Re: Maint-only commits

[Stephen Bash]

----- Original Message -----
> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Monday, May 16, 2011 6:05:07 PM
> Subject: Re: Maint-only commits
> 
> > In my office we've recently run into three separate fixes required
> > on our maintenance branch that should not be included in master (our
> > normal workflow is to make changes on maint, tag, release, and then merge
> > to master). Normally these "maint only" fixes are interspersed with
> > commits that should go back into master. In the past the "maint
> > only" commits were rare, so I'd carefully use "merge -s ours" to avoid
> > including the "maint only" changes in master. But now I'm wondering
> > if there's a better process/workflow?
> 
> I wonder what these "maint only" changes are, and the most importantly, if
> you know if a change you are about to commit is "maint only" material
> at the time you make it, or if it is something you would notice
> retroactively only when it is time to prepare merging maint back to master.

The three recent cases have all been fixes that, due to refactoring on master, require different changes on the two branches (these specific changes have been non-conflicting in a merge sense, but incorrect in a code sense).  All three cases were known ahead of time as "maint only", but unfortunately the first one still snuck through the merge process and had to be reverted on master.

> Assuming the former, you can use exactly the same discipline you already
> use to keep your 'maint' free of commits you make on 'master' to add
> new features that shouldn't be in the maintenance track.

... <snip> ...

> - You would keep for-both-maint-and-master, maint, and master
> branches.
> 
> - You treat the for-both-maint-and-master branch the way maint branch
> in projects like git itself is treated, i.e. everything can go to
> master. Commit changes that are meant for both maint and master on
> this branch, either by committing directly on it, or forking a topic from a
> commit on that branch and committing on top of it.
> 
> - You merge for-both-maint-and-master into maint and master at
> appropriate times.
> 
> - You never merge maint to master, nor merge master to maint.
> 
> - You commit changes that should only go to master on master, either
> by committing directly on it, or forking a topic from a commit on that
> branch and committing on top of it.
> 
> - You commit changes that should only go to maint on maint, either by
> committing directly on it, or forking a topic from a commit on that
> branch and committing on top of it.

That's certainly a valid approach.  I discussed it around the office and got push back on adding additional complexity to our branching model.  So I'll document the "our" merge approach and perhaps revisit the branching model at the beginning of the next development cycle.

Thanks,
Stephen

Re: Maint-only commits

[Jay Soffian]

On Tue, May 17, 2011 at 10:20 AM, Stephen Bash <bash@genarts.com> wrote:
> That's certainly a valid approach.  I discussed it around the office and got push back on adding additional complexity to our branching model.  So I'll document the "our" merge approach and perhaps revisit the branching model at the beginning of the next development cycle.

At @work we use something like this. We have three branches:

- trunk (aka master, but it started as a git-svn branch long ago...)
- release
- maint

Our maint merges to both trunk and release, via an automated process
except when a conflict requires human intervention.

Occasionally someone will put something on trunk by accident that
should've gone to maint. We revert it from trunk, cherry-pick to
maint, and let it merge back down.

(Aside, I've found hudson^wjenkins to be great for misc jobs like this
and prefer it to cron these days for non-sytem-related periodic
events.)

j.

Re: Maint-only commits

[Enrico Weigelt]

* Stephen Bash <bash@genarts.com> wrote:
> Hi all-
> 
> In my office we've recently run into three separate fixes 
> required on our maintenance branch that should not be 
> included in master (our normal workflow is to make changes 
> on maint, tag, release, and then merge to master).  Normally 
> these "maint only" fixes are interspersed with commits that 
> should go back into master.  In the past the "maint only" 
> commits were rare, so I'd carefully use "merge -s ours" 
> to avoid including the "maint only" changes in master.  
> But now I'm wondering if there's a better process/workflow? 

Of course, there is: use topic branches and rebase.


Assuming you've found a bug in maint, which is also still
in master.

#1: for off a topic branch (for that bug) from maint
#2: fix the bug there
#3: rebase to latest maint (if changed meanwhile) and test carefully
#4: (ff-)merge your bugfix branch to maint
#5: rebase bugfix branch to master (maybe incremental, if they
    went too far away from another) and test carefully
#6: (ff-)merge bugfix branch to master
#7: drop that topic branch, as you're done now.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------