{"thread":{"id":"14962","subject":"TopGit: problem with patch series generation","startedAt":"2008-08-12T16:18:54Z","lastAt":"2008-08-13T00:18:09Z","messageCount":11,"participants":["martin f krafft","Avery Pennarun","Petr Baudis","Bert Wesarg","Santi Béjar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"86941","messageId":"20080812161854.GB30067@lapse.rw.madduck.net","threadId":"14962","inReplyTo":null,"subject":"TopGit: problem with patch series generation","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2008-08-12T16:18:54Z","receivedAt":"2008-08-12T16:18:54Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"Hi folks,\n\nI am playing around with TopGit and encountered a (conceptual)\nproblem. I'd love to hear some input.\n\nI want to use TopGit for distro packaging. Any of my packages have\none or more feature branches, some intended for upstream, some\ndistro-specific. As I am packaging TopGit for Debian, I encountered\nthe situation that two branches conflict with each other (they\nchange the same line), but there is no dependency between the\nbranches. Thus, when I squash the branches into a series, the\nresulting patches will not apply (they both change the same original\nline to something else).\n\nObviously, I can introduce a \"fake\" dependency to force TopGit to\ncreate one patch based on another. However, this then prevents me\nfrom testing and developing the depending branch in isolation,\nmeaning that I always have to have the dependent branch applied when\nI want to work on the second feature. Furthermore, it's not\ntrivially possible in this situation to cherry-pick only the second\npatch.\n\nI see that this is a hard problem with no obvious solution. The only\nthing that comes to my mind is maintaining multiple patches for each\nbranch. In the above, if B \"fake-depends\" on A, which depends on\nmaster, then I would have A and B depend on master only, but have\nTopGit also manage B2 for me, which is a diff against A.\n\nDoing this for all branches is polynomial, but then again, the\nnumber of independent branches, or rather branch trees, is likely to\nbe pretty low in most cases.\n\nAs an alternative, it may be possible, however, to let TopGit know\nabout a \"fake dependency\" from B on A. When serialised, TopGit would\nnotice that there are multiple paths from master to B (master->B and\nmaster->A->B) and use the longer one.\n\nDo you see any other ways in which the situation could be handled?\n\nIs the above something that TopGit could learn, Petr?\n\nCheers,\n\n-- \n .''`. martin f. krafft \n: :' : proud Debian developer, author, administrator, and user\n`. `'` http://people.debian.org/~madduck - http://debiansystem.info\n `- Debian - when you have better things to do than fixing systems\n \n\"with sufficient thrust, pigs fly just fine. however, this is not\n necessarily a good idea. it is hard to be sure where they are going\n to land, and it could be dangerous sitting under them as they fly\n overhead.\"\n -- rfc 1925\n\n\n"},{"id":"86943","messageId":"32541b130808120925y663967ebm38eced6df77ffe4@mail.gmail.com","threadId":"14962","inReplyTo":"20080812161854.GB30067@lapse.rw.madduck.net","subject":"Re: TopGit: problem with patch series generation","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-08-12T16:25:36Z","receivedAt":"2008-08-12T16:25:36Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Aug 12, 2008 at 12:18 PM, martin f krafft wrote:\n> As I am packaging TopGit for Debian, I encountered\n> the situation that two branches conflict with each other (they\n> change the same line), but there is no dependency between the\n> branches. Thus, when I squash the branches into a series, the\n> resulting patches will not apply (they both change the same original\n> line to something else).\n\nIsn't this what git-rerere is for? If TopGit doesn't use rerere,\nmaybe it would be easy to add...\n\nHave fun,\n\nAvery\n"},{"id":"86951","messageId":"20080812173257.GK10151@machine.or.cz","threadId":"14962","inReplyTo":"20080812161854.GB30067@lapse.rw.madduck.net","subject":"Re: TopGit: problem with patch series generation","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-12T17:32:57Z","receivedAt":"2008-08-12T17:32:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Tue, Aug 12, 2008 at 01:18:54PM -0300, martin f krafft wrote:\n> I want to use TopGit for distro packaging. Any of my packages have\n> one or more feature branches, some intended for upstream, some\n> distro-specific. As I am packaging TopGit for Debian, I encountered\n> the situation that two branches conflict with each other (they\n> change the same line), but there is no dependency between the\n> branches. Thus, when I squash the branches into a series, the\n> resulting patches will not apply (they both change the same original\n> line to something else).\n\n yes, that is good point.\n\n> Obviously, I can introduce a \"fake\" dependency to force TopGit to\n> create one patch based on another. However, this then prevents me\n> from testing and developing the depending branch in isolation,\n> meaning that I always have to have the dependent branch applied when\n> I want to work on the second feature. Furthermore, it's not\n> trivially possible in this situation to cherry-pick only the second\n> patch.\n\n Well, at least we're not _worse_ off than when using a classical patch\nseries instead of TopGit, since all the downsides would be the same as\nif we had this \"fake dependency\", right? Though of course, it would be\nnice if we could do better here.\n\n> As an alternative, it may be possible, however, to let TopGit know\n> about a \"fake dependency\" from B on A. When serialised, TopGit would\n> notice that there are multiple paths from master to B (master->B and\n> master->A->B) and use the longer one.\n\n I'm sorry, I don't follow you here. If there is a dependency, TopGit\nwill always serialize A first, if there is no dependency, reordering\nwon't help you since B's base won't accomodate A.\n\n> Do you see any other ways in which the situation could be handled?\n\n\n First, let's consider the simplest situation:\n\n\tA--C\n /\n\tB.\n\n(These are branches, not commits!)\n\n In this case, we _CAN_ actually serialize A,B by doing a \"resolution\nsling\" operation - simply take diff(A,C) instead of diff(B^,B)!\n\n The trouble is that we will have:\n\n\tA1--A2--A3--A4--C\n /\n\tB1--B2--B3--B4.\n\n Here, we would have to squash B1..B4 to B in order to be able to do\nthis, which is of course undesirable. We want to sling the C resolution\nin front of B1, and there seems to be no simple way to do this - or can\nanyone see any?\n\n So we would have to ask the user to propagate it instead. Let's call\nthese \"tie branches\":\n\n\tA1--A2--A3--A4------------------C\n\t\t \\ /\n\t\t T1--T2--T3--T4 /\t\ttree(T4) == tree(C)\n\t\t / / / / /\n\t\t B1--B2--B3--B4--'\n\n I guess this is just a more formalized way of rewording your other\nproposal. Then, TopGit, instead of directly setting up C_base by merging\nA4+B4, would create the tie branches T1..T4 and use T4 as C_base.\n\n I'm not really happy about this idea, though. It would complicate\nTopGit even much more than it is now, and I'm not sure if this is worth\nit instead of just requiring you to maintain your dependencies more\ncarefully when you intend to serialize your series later.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"86952","messageId":"20080812175206.GA9131@lapse.rw.madduck.net","threadId":"14962","inReplyTo":"32541b130808120925y663967ebm38eced6df77ffe4-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org","subject":"Re: TopGit: problem with patch series generation","fromName":"martin f krafft","fromEmail":"madduck-jx/+c5dph7vr7s880joybq@public.gmane.org","sentAt":"2008-08-12T17:52:06Z","receivedAt":"2008-08-12T17:52:06Z","isPatch":false,"sender":{"key":"madduck-jx/+c5dph7vr7s880joybq@public.gmane.org","avatar":null},"body":"also sprach Avery Pennarun [2008.08.12.1325 -0300]:\n> Isn't this what git-rerere is for? If TopGit doesn't use rerere,\n> maybe it would be easy to add...\n\nI'd rather avoid the need to replay conflict resolution and do it in\none place only. It always seemed to me that git-rerere is a solution\nto a problem that could have been avoided.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"it is only the modern that ever becomes old-fashioned.\" \n -- oscar wilde\n \nspamtraps: madduck.bogus-JX/+c5DPh7vR7s880joybQ@public.gmane.org\n\n\n_______________________________________________\nvcs-pkg-discuss mailing list\nvcs-pkg-discuss-XbBxUvOt3X2LieD7tvxI8l/i77bcL1HB@public.gmane.org\nhttp://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss\n"},{"id":"86963","messageId":"36ca99e90808121154l1f7978a1v4de40d990005cb0e@mail.gmail.com","threadId":"14962","inReplyTo":"32541b130808120925y663967ebm38eced6df77ffe4@mail.gmail.com","subject":"Re: TopGit: problem with patch series generation","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2008-08-12T18:54:00Z","receivedAt":"2008-08-12T18:54:00Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Aug 12, 2008 at 18:25, Avery Pennarun wrote:\n> On Tue, Aug 12, 2008 at 12:18 PM, martin f krafft wrote:\n>> As I am packaging TopGit for Debian, I encountered\n>> the situation that two branches conflict with each other (they\n>> change the same line), but there is no dependency between the\n>> branches. Thus, when I squash the branches into a series, the\n>> resulting patches will not apply (they both change the same original\n>> line to something else).\n>\n> Isn't this what git-rerere is for? If TopGit doesn't use rerere,\n> maybe it would be easy to add...\nI thought about this too, but have no experience with rerere.\n\nBert\n>\n> Have fun,\n>\n> Avery\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"86973","messageId":"8aa486160808121428t259f5340x6d1a14cadedac30c@mail.gmail.com","threadId":"14962","inReplyTo":"20080812161854.GB30067@lapse.rw.madduck.net","subject":"Re: TopGit: problem with patch series generation","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2008-08-12T21:28:42Z","receivedAt":"2008-08-12T21:28:42Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Tue, Aug 12, 2008 at 18:18, martin f krafft wrote:\n> Hi folks,\n>\n> I am playing around with TopGit and encountered a (conceptual)\n> problem. I'd love to hear some input.\n>\n> I want to use TopGit for distro packaging. Any of my packages have\n> one or more feature branches, some intended for upstream, some\n> distro-specific. As I am packaging TopGit for Debian, I encountered\n> the situation that two branches conflict with each other (they\n> change the same line), but there is no dependency between the\n> branches. Thus, when I squash the branches into a series, the\n> resulting patches will not apply (they both change the same original\n> line to something else).\n>\n\nI don´t know if it fits topgit, but this is what Junio uses:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/24498\n\nBasically he creates a new feature branch that is the merge of the\nconflicting branches (it works for both semantically and explicit\nconficts), and there he resolves the conficts. Then if one of the\nbranches are merged in master (in you case a patch is created) then\nthe other branch fast-forward to the merge.\n\nHTH,\n\nSanti\n"},{"id":"86981","messageId":"20080812224155.GB15521@lapse.rw.madduck.net","threadId":"14962","inReplyTo":"8aa486160808121428t259f5340x6d1a14cadedac30c@mail.gmail.com","subject":"Re: TopGit: problem with patch series generation","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-08-12T22:41:55Z","receivedAt":"2008-08-12T22:41:55Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Santi Béjar [2008.08.12.1828 -0300]:\n> I don´t know if it fits topgit, but this is what Junio uses:\n> \n> http://article.gmane.org/gmane.comp.version-control.git/24498\n\nI think this is definitely something TopGit can automate.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"life is what happens to you while you're busy making other plans.\"\n -- john lennon\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"86983","messageId":"20080812225916.GN10151@machine.or.cz","threadId":"14962","inReplyTo":"20080812224155.GB15521@lapse.rw.madduck.net","subject":"Re: TopGit: problem with patch series generation","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-12T22:59:16Z","receivedAt":"2008-08-12T22:59:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 12, 2008 at 07:41:55PM -0300, martin f krafft wrote:\n> also sprach Santi Béjar [2008.08.12.1828 -0300]:\n> > I don´t know if it fits topgit, but this is what Junio uses:\n> > \n> > http://article.gmane.org/gmane.comp.version-control.git/24498\n> \n> I think this is definitely something TopGit can automate.\n\nThis seems to be in principle the same as the tie branches. It might\nmake sense to have a way to _optionally_ make a tie branch.\n\nHow should that work? Maybe there needs to be even an explicit support\nfor this - should TopGit just check the dependency tree when\nsequencing the topic branches and have a step that says:\n\n\t\"I'm going to sequence branch A. If there is branch T that has\n\tonly already sequenced branches + branch A as dependencies,\n\tuse T's content instead of A.\"\n\nWould that be satisfactory?\n\nFinding out this information would be very expensive, of course. But for\nother reasons, we might want to keep a cache of branch dependencies.\n\nOf course, in the case of\n\n A1--A2--A3--A4--C\n /\n B1--B2--B3--B4.\n\nthe sequenced branches would still be like\n\n A1--A2--A3--A4--B1--B2--B3--C\n\nunless you create the T1..T4 branches manually.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"86984","messageId":"20080812230727.GB16481@lapse.rw.madduck.net","threadId":"14962","inReplyTo":"20080812173257.GK10151@machine.or.cz","subject":"Re: TopGit: problem with patch series generation","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-08-12T23:07:27Z","receivedAt":"2008-08-12T23:07:27Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Petr Baudis [2008.08.12.1432 -0300]:\n> I'm not really happy about this idea, though. It would complicate\n> TopGit even much more than it is now, and I'm not sure if this is\n> worth it instead of just requiring you to maintain your\n> dependencies more carefully when you intend to serialize your\n> series later.\n\nSure, but there are no dependencies between some of these branches.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"i worked myself up from nothing to a state of extreme poverty.\"\n -- groucho marx\n \nspamtraps: madduck.bogus@madduck.net\n\n\n"},{"id":"86985","messageId":"20080812231037.GC16481@lapse.rw.madduck.net","threadId":"14962","inReplyTo":"20080812225916.GN10151-DDGJ70k9y3lX+M3pkMnKjw@public.gmane.org","subject":"Re: TopGit: problem with patch series generation","fromName":"martin f krafft","fromEmail":"madduck-jx/+c5dph7vr7s880joybq@public.gmane.org","sentAt":"2008-08-12T23:10:37Z","receivedAt":"2008-08-12T23:10:37Z","isPatch":false,"sender":{"key":"madduck-jx/+c5dph7vr7s880joybq@public.gmane.org","avatar":null},"body":"also sprach Petr Baudis [2008.08.12.1959 -0300]:\n> > I think this is definitely something TopGit can automate.\n> \n> This seems to be in principle the same as the tie branches. It might\n> make sense to have a way to _optionally_ make a tie branch.\n\nYes, optional would make sense!\n\n> How should that work? Maybe there needs to be even an explicit support\n> for this - should TopGit just check the dependency tree when\n> sequencing the topic branches and have a step that says:\n> \n> \t\"I'm going to sequence branch A. If there is branch T that has\n> \tonly already sequenced branches + branch A as dependencies,\n> \tuse T's content instead of A.\"\n> \n> Would that be satisfactory?\n\nYes, that's what I was thinking about, if I read you correctly.\n\n> Of course, in the case of\n> \n> A1--A2--A3--A4--C\n> /\n> B1--B2--B3--B4.\n> \n> the sequenced branches would still be like\n> \n> A1--A2--A3--A4--B1--B2--B3--C\n> \n> unless you create the T1..T4 branches manually.\n\nYes. Or add a dependency. I'd just prefer not to add a dependency\nwhere there is none; instead, I'd prefer if TopGit could be aided\nwith the serialisation in cases when it cannot possibly make\na proper decision.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"a mathematician is a device for turning coffee into theorems.\"\n -- paul erdös\n \nspamtraps: madduck.bogus-JX/+c5DPh7vR7s880joybQ@public.gmane.org\n\n\n_______________________________________________\nvcs-pkg-discuss mailing list\nvcs-pkg-discuss-XbBxUvOt3X2LieD7tvxI8l/i77bcL1HB@public.gmane.org\nhttp://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss\n"},{"id":"86991","messageId":"20080813001809.GO10151@machine.or.cz","threadId":"14962","inReplyTo":"20080812231037.GC16481@lapse.rw.madduck.net","subject":"Re: TopGit: problem with patch series generation","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-13T00:18:09Z","receivedAt":"2008-08-13T00:18:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 12, 2008 at 08:10:37PM -0300, martin f krafft wrote:\n> also sprach Petr Baudis [2008.08.12.1959 -0300]:\n> > How should that work? Maybe there needs to be even an explicit support\n> > for this - should TopGit just check the dependency tree when\n> > sequencing the topic branches and have a step that says:\n> > \n> > \t\"I'm going to sequence branch A. If there is branch T that has\n> > \tonly already sequenced branches + branch A as dependencies,\n> > \tuse T's content instead of A.\"\n> > \n> > Would that be satisfactory?\n> \n> Yes, that's what I was thinking about, if I read you correctly.\n\nBut we _REALLY_ want to do this only for stage branches!\n\n> > Of course, in the case of\n> > \n> > A1--A2--A3--A4--C\n> > /\n> > B1--B2--B3--B4.\n> > \n> > the sequenced branches would still be like\n> > \n> > A1--A2--A3--A4--B1--B2--B3--C\n> > \n> > unless you create the T1..T4 branches manually.\n> \n> Yes. Or add a dependency. I'd just prefer not to add a dependency\n> where there is none; instead, I'd prefer if TopGit could be aided\n> with the serialisation in cases when it cannot possibly make\n> a proper decision.\n\nYes, and it should certainly warn you about this at any rate, and give\nyou a chance to resolve this manually - possibly taking advantage of\nrerere.\n\nSo, my idea: tg export --quilt should set up and maintain a private\nworking branch where it merges all the exported branches, one-by-one\n(possibly doing the sling as described above first). In case there is a\nconflict, it either aborts or gives you a chance to resolve it and go on\nwith the export. It could also offer you to save your resolution in a\nnew tie branch for future auto-slinging, but it would be tricky to\nfigure out exactly what patches does it depend on.\n\nOverally, I'd start simply with implementing the sequential merge and\nforget about slinging resolutions from tie branches. The former should\nbe very simple and solve most of the cases, especially when using rerere.\nFor the hairy cases, you can just add a dependency for now - sort of\npreliminary serialization. :-)\n\nThe slinging might be feasible, but would be much more complicated\nto implement. I think this can simply wait.\n\nBut to be clear, I don't plean to do any of this myself in the near\nfuture anyway, since this case is not that important for me - I now need\nTopGit to support remote topic branches instead. So if this is a\npriority for you, you need to implement this on your own. But the\nsequential merge part should be really easy, just something like\n\n\tgit checkout -b tmp\n\tforeach patch_branch\n\t\tgit merge patch_branch\n\t\tcat .topmsg >output/patch.diff\n\t\tgit diff HEAD^..HEAD >>output/patch.diff\n\nwith all the frills. ;-) (Maybe make a special \"show diff between X and\nY instead of base and head\" flag for tg patch so that we can rely on it\nfor the frills.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"}]}