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

[Michael J Gruber <git@drmicha.warpmail.net>]

Adam Monsen venit, vidit, dixit 14.02.2011 22:50:
> 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