Re: [RFC] cherry-pick using multiple parents to implement -x

[Paolo Bonzini <bonzini@gnu.org>]

Junio C Hamano wrote:
> "Stephen R. van den Berg" <srb@cuci.nl> writes:
>> The questions now are:
>> - Would there be good reason not to record the backport/forwardport
>>   relationship in the additional parents of a commit?
> 
> In general, I do not think what you did is a good idea.

I agree with this, though I can see the motivation (for example that
git-patch-id, and hence git-cherry, often do not work because of context
changes).

This thread, however, spurred one observation and a question.

Observation: it seems to me that cherry-picking and merging are mutually
exclusive workflows.  You cherry-pick from a development branch to a
stable branch, you merge or rebase in the other direction.  Is this true
in general?  (I can see the obvious exception: you might cherry-pick
that very important bugfix, if you're not ready to do a full merge; but
if you rebase, that commit will go away as soon as you do it).

Question: how are topic branches managed in git.git?  In particular, how
are "graduations to master" done?  Do you cherry-pick the merge commit
that went into "next"?

Paolo