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@xxxxxxxx> [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 | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html