Re: [RFC] cherry-pick using multiple parents to implement -x
- From
Paolo Bonzini <bonzini@gnu.org>
- Date
- Sep 8, 2008, 07:37 UTC
- Message-ID
- <48C4D631.3010604@gnu.org>
- In-Reply-To
- <7vtzcrn9uv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
Show 6 quoted lines
> "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