Re: [Core GIT] Long-term cherrypicking

Greg KH [off-list ref] wrote:

On Wed, Sep 21, 2005 at 06:40:15PM +0200, Petr Baudis wrote:

quoted

  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

Dear diary, on Thu, Sep 22, 2005 at 11:53:27AM CEST, I got a letter
where Catalin Marinas [off-list ref] told me that...

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 would be pretty ugly since the same patches would re-appear in the
commit graph in another incarnations many times.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.