Re: Maint-only commits

Stephen Bash [off-list ref] 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.

----- Original Message -----

From: "Junio C Hamano" <redacted>
Sent: Monday, May 16, 2011 6:05:07 PM
Subject: Re: Maint-only commits

quoted

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

On Tue, May 17, 2011 at 10:20 AM, Stephen Bash [off-list ref] 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.