From: Adam Monsen <haircut@gmail.com>
Date: Tue, 15 Feb 2011 21:03:43 GMT
Subject: release maintenance vs. release engineering (was: configuring cherry-pick to always use -x?)
Message-ID: <4D5AEA2F.9000606@gmail.com>
In-Reply-To: <4D5A401B.1050103@drmicha.warpmail.net>

Michael J Gruber wrote:
> I don't quite understand how cherry picks could conflict less then
> merges if the release branch contains fixes only.

The last time I experienced a painful merge from f-release to master, it
was because some files had been culled from master but left extant on
f-release. Not too hard to resolve, actually. But I really only needed
one change pulled into master, and when I cherry picked instead of
merging the whole branch, there were no conflicts, and master ended up
containing exactly what I wanted.

> My impression is that "f-release" actually
> mixes release engineering and maintenance. Two possible remedies:
> 
> - Separate release engineering from maintenance and merge only the
> latter to master

Ah, thank you! This is invaluable advice. I think I'll go with this
option since mixing release engineering and maintenance is exactly what
I'm doing. Hopefully it's worth the added complexity of having another
public branch.

I pushed an example to https://github.com/meonkeys/releaseBranchDemo
that I'll share with my developers.

"git merge -sours" will definitely be something useful to add to the
quiver too.