Re: [Core GIT] Long-term cherrypicking

From: Greg KH <greg@kroah.com>
Date: Sep 22, 2005, 08:31 UTC
Message-ID: <20050922083142.GA6866@kroah.com>
In-Reply-To: <20050921164015.GC21971@pasky.or.cz>

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

Show 13 quoted lines

>   Hello,
> 
>   I've been working out some workflow possibilities with Karsten Keil at
> the SuSE Labs conference, and I'd like to see your opinions. His
> position does not seem unique at all, so I'm a bit surprised that noone
> solved this before, or at least I didn't find any documentation about
> this in the tutorial and howtos (or perhaps I missed it?).
> 
>   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.

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.

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.)

thanks,

greg k-h