Re: Maint-only commits

From: Stephen Bash <bash@genarts.com>
Date: May 17, 2011, 14:20 UTC
Message-ID: <32603283.31527.1305642038158.JavaMail.root@mail.hq.genarts.com>
In-Reply-To: <7vliy6jo8c.fsf@alter.siamese.dyndns.org>

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

Show 17 quoted lines

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

Show 21 quoted lines

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