Re: configuring cherry-pick to always use -x?

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Feb 15, 2011, 08:58 UTC
Message-ID: <4D5A401B.1050103@drmicha.warpmail.net>
In-Reply-To: <4D59A39C.9090402@gmail.com>

Adam Monsen venit, vidit, dixit 14.02.2011 22:50:

Show 21 quoted lines

> Junio C Hamano wrote:
>> could you please justify in what workflow it would make sense to use
>> -x most of the time?
> 
> Sure. Summary: two long-lived publicly visible branches.
> 
> Details:
> Mifos is what I'm usually working on lately. We have branches "master"
> and "f-release" both present in our public git repository called "head"
> (hosted at sf.net). master is the bleeding edge of development,
> f-release is a release maintenance branch recently created off the tip
> of master. I expect both to live on forever (even though commits to
> f-release will eventually cease).
> 
> Right after f-release was cut, we merged f-release to master every day
> or so to make sure bugfixes for f-release were also propagated to future
> releases. After a while, merging resulted in too many conflicts and we
> started cherry picking instead.
> 
> This process is described generally at
> http://mifosforge.jira.com/wiki/display/MIFOS/Release+Branch+Merging+Policy

I don't quite understand how cherry picks could conflict less then merges if the release branch contains fixes only. Also, I don't think the advice to use "merge+revert" is a good one. All of this indicates a suboptimal use of branches. 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

- If you do want them on the same branch "f-release", you probably know
beforehand which commits you don't want on master. You can fake-merge
these ("merge -Xours") to master and merge the others, which is somewhat
ugly but still better than cherry-picking everything. In some sense this
is "manual rerere" whose results are shared (pushed) easily.(*)

Michael

(*) If that is cryptic, I mean something like:

git checkout master git merge f-release #be happy if it succeeds, identify problematic commit X if not; decide whether X belongs on master; if yes resolve, if not reset and: git merge X^ git merge -Xours X #back to start