Re: [TopGit] Multiple concurrent sets of patches

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

On Tue, Mar 03, 2009 at 08:22:21PM +0100, Jonas Smedegaard wrote:
> On Tue, Mar 03, 2009 at 02:03:16PM +0100, martin f krafft wrote:
> >also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:
> >> It seems to me that TopGit is incapable of handling this. That it can 
> >> only handle patchset against a single branch, and if the need arise 
> >> for restructuring an additional patchset for e.g. a stable or 
> >> oldstable branch, then quilt needs to be used manually anyway.
> >
> >Let me try to understand you: you want TopGit to maintain a single
> >feature branch against two different source branches? How should
> >that work? Could you elaborate a bit so that your needs become a bit
> >more obvious?
> 
> Not quite. I want TopGit to maintain multiple feature branches, 
> preferrably related.
> 
> With "related" I mean that I would like to be able to "fork" a chain of 
> interdependent feature branches.
> 
> TopGit easily support one chain of branches:
> 
> upstream + pristine-tar -> master -> build
> 
> I want TopGit to additionally support the following:
> 
> upstream + pristine-tar -> stable-master -> stable-build
> 
> upstream + pristine-tar -> oldstable-master -> oldstable-build
> 
> 
> E.g. in addition to TopGit branches t/fix_01 and t/feature_01 I would 
> want to fork those branches as t_stable/fix_01 and t_stable/feature_01.
> 
> 
> I know that I can create all those TopGit branches one by one, but I 
> would then need to explicitly declare a list of TopGit branches to apply 
> each time I want to (re)generate a quilt patchlist.
For my kernel development I use topgit topic branches that collect
topgit patch branches.  Take this dependency graph:

	linus/master <- t/armmisc/patch1 <- t/armmisc-master <- t/armmisc-pu
	         ^ ^----t/armmisc/patch2 <--'                   |
                 `------t/armmisc/patch3 <----------------------'

So t/armmisc-master collects patches that are ready for upstream, -pu
patches that need some more work.

With etch <- lenny <- squeeze <- sid you could do the same.  The only
Consider you have a security fix that is relevant for all
releases starting at lenny. Then you do

	tg create t/fixes-lenny/CVE-2009-abcd master-lenny
	... apply patch
	... fill .topmsg
	git commit

	git checkout t/fixes-lenny-master
	tg depend add t/fixes-lenny/CVE-2009-abcd

	tg create t/fixes-squeeze/CVE-2009-abcd master-squeeze t/fixes-etch/CVE-2009-abcd
	... no need to apply patch
	... cherry-pick .topmsg from t/fixes-lenny/CVE-2009-abcd
	git commit

	git checkout t/fixes-squeeze-master
	tg depend add t/fixes-squeeze/CVE-2009-abcd
	
And if you notice that etch needs the same fix, you can create
t/fixes-etch/CVE-2009-abcd based on master-etch and then do

	git checkout t/fixes-lenny/CVE-2009-abcd
	tg depend add t/fixes-etch/CVE-2009-abcd

tatata, I think that's it for packaging.

But this doesn't help me for my kernel problem, because here I don't
have that ordering on releases.  I want to manage patches on top of
linux-tip and the ARM tree, but none of these contains the other :-/

Best regards
Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |
Peiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686              | Fax:   +49-5121-206917-5555 |