Re: [Core GIT] Long-term cherrypicking

[Catalin Marinas <catalin.marinas@gmail.com>]

Greg KH <greg@kroah.com> wrote:
> On Wed, Sep 21, 2005 at 06:40:15PM +0200, Petr Baudis wrote:
>>   His situation is that he has some patches in the ISDN subsystem, a
>> public repository, but sends the patches over e-mail to Linus. So he is
>> something between the subsystem maintainer and individual developer in
>> the categories listed out in the tutorial. What should be his merging
>> strategy?
>
> Not to use git for this.
>
> Seriously, that's what I have switched to doing, and it's so much
> easier.  I use quilt to manage patches from the community, and Andrew
> pulls them into to the -mm releases, and all users can test them.  I
> keep them up to date with the git snapshots, which handles the different
> merge and fuzz issues very well.

You might want to try StGIT as well, unless you have a huge number of
patches and rebasing them takes too much time. It follows the quilt
ideas but it does a three-way merge instead of patch+fuzz. This allows
it to detect patches accepted by Linus and also see whether they were
not fully applied or were modified. You can run 'stg export' to
generate a patch series to send to Andrew.

> Then, when it's time to merge with Linus, I pick and choose the patches
> that I want to send off, create a git tree, add them to the tree, and
> send them off.

With StGIT, you can either use 'stg mail <patches...>' or re-organise
the stack with push/pop so that you only keep the patches to be merged
by Linus and tell him the HEAD value to merge. Even if you modify the
stack afterwards, the HEAD value still represents the stack state at
that moment (unless you run 'git prune' and the value is not saved in
a file under refs/heads/).

StGIT also support cherry-picking via 'stg import --commit=...' if you
want to create a separate branch.

But what I understand from Petr's e-mail is that re-basing the patches
is not acceptable for a repository which is public. One option would
be to keep a private tree where the patches are re-based and a public
one which periodically pulls from Linus' tree and your private
one. Not sure how complicated the commit graph would look.

> It's ended up saving me a lot of time (I used to do what Karsten is
> trying to do with bitkeeper, and it had the same issues that he is
> running into) and would recommend this situation for anyone who wants to
> keep patches from being merged immediatly (like he is trying to do.)

I only maintain a small set of patches (< 20) and send some of them
upstream via RMK. I would recommend StGIT :-) as an alternative to
quilt (I don't say a better one but some people might like it).

-- 
Catalin