{"thread":{"id":"18106","subject":"[TopGit] Multiple concurrent sets of patches","startedAt":"2009-03-03T11:37:41Z","lastAt":"2009-03-04T07:16:17Z","messageCount":6,"participants":["Jonas Smedegaard","martin f krafft","Uwe Kleine-König"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"106821","messageId":"20090303113741.GO12820@jones.dk","threadId":"18106","inReplyTo":null,"subject":"[TopGit] Multiple concurrent sets of patches","fromName":"Jonas Smedegaard","fromEmail":"dr@jones.dk","sentAt":"2009-03-03T11:37:41Z","receivedAt":"2009-03-03T11:37:41Z","isPatch":false,"sender":{"key":"dr@jones.dk","avatar":"https://gravatar.com/avatar/c7abd877327336e09864292f002c737f3614d0192f27bbcdcb07d03cf20cbed3?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nHi,\n\nI have run into a challenge that I suspect is a limitation of current \nTopGit. I am hoping you could help enlighten me, as I otherwise feel \nthat TopGit is not generally usable for my Debian packaging needs:\n\nHow to manage patches against multiple source branches using TopGit?\n\nLet's take netatalk as an example. Upstream only quite infrequently \nrelease new upstream tarball releases, so I cherry-pick patches from \nupstream VCS. Recently a security-related bug was discovered which \nneeded fixing not only in the current packaging development (git master \nbranch) but also needed branching off earlier releases of the package \n(those included in the \"stable\" and \"oldstable\" Debian distro releases) \nand applying same fix for them.\n\nThe actual patch needed for the various branches was obviously not \nidentical, as upstream sources were different and my cherry-picked set \nof patches had evolved.\n\nIt seems to me that TopGit is incapable of handling this. That it can \nonly handle patchset against a single branch, and if the need arise for \nrestructuring an additional patchset for e.g. a stable or oldstable \nbranch, then quilt needs to be used manually anyway.\n\n\n   - Jonas\n\nDebian developer\n\n- -- \n* Jonas Smedegaard - idealist og Internet-arkitekt\n* Tlf.: +45 40843136  Website: http://dr.jones.dk/\n\n   [x] quote me freely  [ ] ask before reusing  [ ] keep private\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niEYEARECAAYFAkmtFoUACgkQn7DbMsAkQLgvrACdHfy5K0igPa6Yj/LYyhh3Llyn\njvcAnRfla1QyuUrx8+L4IL9XYY2CB+Su\n=B1Kc\n-----END PGP SIGNATURE-----\n"},{"id":"106833","messageId":"20090303130316.GA17702@piper.oerlikon.madduck.net","threadId":"18106","inReplyTo":"20090303113741.GO12820@jones.dk","subject":"Re: [TopGit] Multiple concurrent sets of patches","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2009-03-03T13:03:16Z","receivedAt":"2009-03-03T13:03:16Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:\n> It seems to me that TopGit is incapable of handling this. That it can \n> only handle patchset against a single branch, and if the need arise for \n> restructuring an additional patchset for e.g. a stable or oldstable \n> branch, then quilt needs to be used manually anyway.\n\nLet me try to understand you: you want TopGit to maintain a single\nfeature branch against two different source branches? How should\nthat work? Could you elaborate a bit so that your needs become a bit\nmore obvious?\n\nThanks,\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"i feel sorry for people who don't drink. when they wake up in the\n morning, that's as good as they're going to feel all day.\"\n                                                    -- frank sinatra\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"106914","messageId":"20090303192221.GV12820@jones.dk","threadId":"18106","inReplyTo":"20090303130316.GA17702@piper.oerlikon.madduck.net","subject":"Re: [TopGit] Multiple concurrent sets of patches","fromName":"Jonas Smedegaard","fromEmail":"dr@jones.dk","sentAt":"2009-03-03T19:22:21Z","receivedAt":"2009-03-03T19:22:21Z","isPatch":false,"sender":{"key":"dr@jones.dk","avatar":"https://gravatar.com/avatar/c7abd877327336e09864292f002c737f3614d0192f27bbcdcb07d03cf20cbed3?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nOn Tue, Mar 03, 2009 at 02:03:16PM +0100, martin f krafft wrote:\n>also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:\n>> It seems to me that TopGit is incapable of handling this. That it can \n>> only handle patchset against a single branch, and if the need arise \n>> for restructuring an additional patchset for e.g. a stable or \n>> oldstable branch, then quilt needs to be used manually anyway.\n>\n>Let me try to understand you: you want TopGit to maintain a single\n>feature branch against two different source branches? How should\n>that work? Could you elaborate a bit so that your needs become a bit\n>more obvious?\n\nNot quite. I want TopGit to maintain multiple feature branches, \npreferrably related.\n\nWith \"related\" I mean that I would like to be able to \"fork\" a chain of \ninterdependent feature branches.\n\nTopGit easily support one chain of branches:\n\nupstream + pristine-tar -> master -> build\n\nI want TopGit to additionally support the following:\n\nupstream + pristine-tar -> stable-master -> stable-build\n\nupstream + pristine-tar -> oldstable-master -> oldstable-build\n\n\nE.g. in addition to TopGit branches t/fix_01 and t/feature_01 I would \nwant to fork those branches as t_stable/fix_01 and t_stable/feature_01.\n\n\nI know that I can create all those TopGit branches one by one, but I \nwould then need to explicitly declare a list of TopGit branches to apply \neach time I want to (re)generate a quilt patchlist.\n\n\nPerhaps what I really am looking for here is something like \"tg tag\":\n\n    git checkout t/fix_01\n    tg tag t/fix_01 master\n    git checkout -b t_stable/fix_01 t/fix_01\n    tg tag -d master\n    tg tag stable\n    git checkout stable_build\n    ./debian/rules tg-export tags=stable\n\n\n...or perhaps this is not relevant upstream to TopGit at all but only to \nyour packaging of a \"tg-export\" rule?\n\n\n    - Jonas\n\n- -- \n* Jonas Smedegaard - idealist og Internet-arkitekt\n* Tlf.: +45 40843136  Website: http://dr.jones.dk/\n\n    [x] quote me freely  [ ] ask before reusing  [ ] keep private\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niEYEARECAAYFAkmtg20ACgkQn7DbMsAkQLhQGQCfQjtfJzzQUu6B0qywpkmxmdGp\n66oAnjEtR2Dc/zJ+lMoP3TD3jy1pr1s9\n=MwTs\n-----END PGP SIGNATURE-----\n"},{"id":"106921","messageId":"20090303194232.GB18423@pengutronix.de","threadId":"18106","inReplyTo":"20090303192221.GV12820@jones.dk","subject":"Re: [TopGit] Multiple concurrent sets of patches","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2009-03-03T19:42:32Z","receivedAt":"2009-03-03T19:42:32Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"On Tue, Mar 03, 2009 at 08:22:21PM +0100, Jonas Smedegaard wrote:\n> On Tue, Mar 03, 2009 at 02:03:16PM +0100, martin f krafft wrote:\n> >also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:\n> >> It seems to me that TopGit is incapable of handling this. That it can \n> >> only handle patchset against a single branch, and if the need arise \n> >> for restructuring an additional patchset for e.g. a stable or \n> >> oldstable branch, then quilt needs to be used manually anyway.\n> >\n> >Let me try to understand you: you want TopGit to maintain a single\n> >feature branch against two different source branches? How should\n> >that work? Could you elaborate a bit so that your needs become a bit\n> >more obvious?\n> \n> Not quite. I want TopGit to maintain multiple feature branches, \n> preferrably related.\n> \n> With \"related\" I mean that I would like to be able to \"fork\" a chain of \n> interdependent feature branches.\n> \n> TopGit easily support one chain of branches:\n> \n> upstream + pristine-tar -> master -> build\n> \n> I want TopGit to additionally support the following:\n> \n> upstream + pristine-tar -> stable-master -> stable-build\n> \n> upstream + pristine-tar -> oldstable-master -> oldstable-build\n> \n> \n> E.g. in addition to TopGit branches t/fix_01 and t/feature_01 I would \n> want to fork those branches as t_stable/fix_01 and t_stable/feature_01.\n> \n> \n> I know that I can create all those TopGit branches one by one, but I \n> would then need to explicitly declare a list of TopGit branches to apply \n> each time I want to (re)generate a quilt patchlist.\nFor my kernel development I use topgit topic branches that collect\ntopgit patch branches.  Take this dependency graph:\n\n\tlinus/master <- t/armmisc/patch1 <- t/armmisc-master <- t/armmisc-pu\n\t         ^ ^----t/armmisc/patch2 <--'                   |\n                 `------t/armmisc/patch3 <----------------------'\n\nSo t/armmisc-master collects patches that are ready for upstream, -pu\npatches that need some more work.\n\nWith etch <- lenny <- squeeze <- sid you could do the same.  The only\nConsider you have a security fix that is relevant for all\nreleases starting at lenny. Then you do\n\n\ttg create t/fixes-lenny/CVE-2009-abcd master-lenny\n\t... apply patch\n\t... fill .topmsg\n\tgit commit\n\n\tgit checkout t/fixes-lenny-master\n\ttg depend add t/fixes-lenny/CVE-2009-abcd\n\n\ttg create t/fixes-squeeze/CVE-2009-abcd master-squeeze t/fixes-etch/CVE-2009-abcd\n\t... no need to apply patch\n\t... cherry-pick .topmsg from t/fixes-lenny/CVE-2009-abcd\n\tgit commit\n\n\tgit checkout t/fixes-squeeze-master\n\ttg depend add t/fixes-squeeze/CVE-2009-abcd\n\t\nAnd if you notice that etch needs the same fix, you can create\nt/fixes-etch/CVE-2009-abcd based on master-etch and then do\n\n\tgit checkout t/fixes-lenny/CVE-2009-abcd\n\ttg depend add t/fixes-etch/CVE-2009-abcd\n\ntatata, I think that's it for packaging.\n\nBut this doesn't help me for my kernel problem, because here I don't\nhave that ordering on releases.  I want to manage patches on top of\nlinux-tip and the ARM tree, but none of these contains the other :-/\n\nBest regards\nUwe\n\n-- \nPengutronix e.K.                              | Uwe Kleine-König            |\nIndustrial Linux Solutions                    | http://www.pengutronix.de/  |\nPeiner Strasse 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |\nAmtsgericht Hildesheim, HRA 2686              | Fax:   +49-5121-206917-5555 |\n"},{"id":"106934","messageId":"20090303220709.GY12820@jones.dk","threadId":"18106","inReplyTo":"20090303194232.GB18423@pengutronix.de","subject":"Re: [TopGit] Multiple concurrent sets of patches","fromName":"Jonas Smedegaard","fromEmail":"dr@jones.dk","sentAt":"2009-03-03T22:07:09Z","receivedAt":"2009-03-03T22:07:09Z","isPatch":false,"sender":{"key":"dr@jones.dk","avatar":"https://gravatar.com/avatar/c7abd877327336e09864292f002c737f3614d0192f27bbcdcb07d03cf20cbed3?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nOn Tue, Mar 03, 2009 at 08:42:32PM +0100, Uwe Kleine-König wrote:\n>On Tue, Mar 03, 2009 at 08:22:21PM +0100, Jonas Smedegaard wrote:\n>> On Tue, Mar 03, 2009 at 02:03:16PM +0100, martin f krafft wrote:\n>> >also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.1237 +0100]:\n>> >> It seems to me that TopGit is incapable of handling this. That it \n>> >> can only handle patchset against a single branch, and if the need \n>> >> arise for restructuring an additional patchset for e.g. a stable \n>> >> or oldstable branch, then quilt needs to be used manually anyway.\n>> >\n>> >Let me try to understand you: you want TopGit to maintain a single \n>> >feature branch against two different source branches? How should \n>> >that work? Could you elaborate a bit so that your needs become a bit \n>> >more obvious?\n>> \n>> Not quite. I want TopGit to maintain multiple feature branches, \n>> preferrably related.\n>> \n>> With \"related\" I mean that I would like to be able to \"fork\" a chain \n>> of interdependent feature branches.\n>> \n>> TopGit easily support one chain of branches:\n>> \n>> upstream + pristine-tar -> master -> build\n>> \n>> I want TopGit to additionally support the following:\n>> \n>> upstream + pristine-tar -> stable-master -> stable-build\n>> \n>> upstream + pristine-tar -> oldstable-master -> oldstable-build\n>> \n>> \n>> E.g. in addition to TopGit branches t/fix_01 and t/feature_01 I would \n>> want to fork those branches as t_stable/fix_01 and t_stable/feature_01.\n>> \n>> \n>> I know that I can create all those TopGit branches one by one, but I \n>> would then need to explicitly declare a list of TopGit branches to \n>> apply each time I want to (re)generate a quilt patchlist.\n>For my kernel development I use topgit topic branches that collect \n>topgit patch branches.  Take this dependency graph:\n>\n>\tlinus/master <- t/armmisc/patch1 <- t/armmisc-master <- t/armmisc-pu\n>\t         ^ ^----t/armmisc/patch2 <--'                   |\n>                 `------t/armmisc/patch3 <----------------------'\n>\n>So t/armmisc-master collects patches that are ready for upstream, -pu\n>patches that need some more work.\n\nMy head is spinning - the dependency graph in my head was upside down \ncompared to your ascii art here.\n\nI think I understand it . Thanks!\n\nI will try it out - I converted ghostscript last week to using TopGit as \nan excercise: good challenge, a nice bunch of patches (but nothing near \nas complex as kernel stuff, I know).\n\n\n>\ttg create t/fixes-squeeze/CVE-2009-abcd master-squeeze t/fixes-etch/CVE-2009-abcd\n>\t... no need to apply patch\n>\t... cherry-pick .topmsg from t/fixes-lenny/CVE-2009-abcd\n>\tgit commit\n\nAbove puzzles me: Is cherry-picking .topmsg just a lazy way to write \nsame description for parallel topicbranch, or is it a trick to cheat \nTopGit into believing that that branch never needs updating?\n\n\n>But this doesn't help me for my kernel problem, because here I don't \n>have that ordering on releases.  I want to manage patches on top of \n>linux-tip and the ARM tree, but none of these contains the other :-/\n\nI can only begin to imagine the complexities of dealing with parallel \ntracks of kernel patching... Good luck with that!\n\n\nThanks a lot for your insight,\n\n  - Jonas\n\n- -- \n* Jonas Smedegaard - idealist og Internet-arkitekt\n* Tlf.: +45 40843136  Website: http://dr.jones.dk/\n\n  [x] quote me freely  [ ] ask before reusing  [ ] keep private\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.9 (GNU/Linux)\n\niEYEARECAAYFAkmtqg0ACgkQn7DbMsAkQLhMFACgkW1FYlWnEP8unk+wVgAkd0i+\nUMwAoKT1mkxIRP6XmNKt+Rj3iJn2yUpM\n=7x2Z\n-----END PGP SIGNATURE-----\n"},{"id":"106950","messageId":"20090304071617.GA23605@piper.oerlikon.madduck.net","threadId":"18106","inReplyTo":"20090303192221.GV12820@jones.dk","subject":"Re: [TopGit] Multiple concurrent sets of patches","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2009-03-04T07:16:17Z","receivedAt":"2009-03-04T07:16:17Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Jonas Smedegaard <dr@jones.dk> [2009.03.03.2022 +0100]:\n> I know that I can create all those TopGit branches one by one, but\n> I would then need to explicitly declare a list of TopGit branches\n> to apply each time I want to (re)generate a quilt patchlist.\n\nThere are two ways to achieve what you want with TopGit. Uwe\noutlined one way:\n\n- create a new branch depending on all the patch branches you want\n  to use. This is what I advocated for packaging in Debian's topgit\n  0.3-1 package:\n  http://git.debian.org/?p=collab-maint/topgit.git;a=blob;f=debian/README.source;hb=debian/topgit-0.3-1\n\n- declare the list of patches to use, as you suggest. This is what\n  the current tg2quilt.mk approach of Debian's topgit 0.5-1 package\n  does.\n\nIn the context where you have a single debian/rules file to prepare\na quilt series as part of building your package, I think the latter\nmakes more sense, as it keeps information in debian/rules and\nalleviates the user of repetetive steps.\n\nHowever, in the special context of a security fix, the suggestion\nillustrated by Uwe probably makes a lot more sense. One reason for\nthis is because it is not yet possible to use TopGit patch branches\nof the past, meaning that you can only ever use the tip of each, and\nthat tg-update basically destroys the infrastructure needed to go\nback in time. By creating a special depending branch for the\nsecurity fix, however, you are preserving the graph at the time,\nwhich is the tag you were alluding to.\n\nThis is what I can add to this discussion. I don't think I have\nactually fully understood the scope of the problem yet.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"no work of art ever puts forward views.\n views belong to people\n who are not artists.\"\n                                                        -- oscar wilde\n \nspamtraps: madduck.bogus@madduck.net\n"}]}