Re: [TopGit] Multiple concurrent sets of patches

[Jonas Smedegaard <dr@jones.dk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Mar 03, 2009 at 08:42:32PM +0100, Uwe Kleine-König wrote:
>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-----