Re: [TopGit] Multiple concurrent sets of patches
- From
Jonas Smedegaard <dr@jones.dk>
- Date
- Mar 3, 2009, 22:07 UTC
- Message-ID
- <20090303220709.GY12820@jones.dk>
- In-Reply-To
- <20090303194232.GB18423@pengutronix.de>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Mar 03, 2009 at 08:42:32PM +0100, Uwe Kleine-König wrote:
Show 46 quoted lines
>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.
My head is spinning - the dependency graph in my head was upside down compared to your ascii art here.
I think I understand it . Thanks!
I will try it out - I converted ghostscript last week to using TopGit as an excercise: good challenge, a nice bunch of patches (but nothing near as complex as kernel stuff, I know).
> 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
Above puzzles me: Is cherry-picking .topmsg just a lazy way to write same description for parallel topicbranch, or is it a trick to cheat TopGit into believing that that branch never needs updating?
>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 :-/
I can only begin to imagine the complexities of dealing with parallel tracks of kernel patching... Good luck with that!
Thanks a lot for your insight,
- Jonas
- -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkmtqg0ACgkQn7DbMsAkQLhMFACgkW1FYlWnEP8unk+wVgAkd0i+ UMwAoKT1mkxIRP6XmNKt+Rj3iJn2yUpM =7x2Z -----END PGP SIGNATURE-----