Re: Maint-only commits

----- 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