{"thread":{"id":"15522","subject":"TopGit: how to deal with upstream inclusion","startedAt":"2008-09-14T20:30:43Z","lastAt":"2008-09-24T18:13:15Z","messageCount":9,"participants":["martin f krafft","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90689","messageId":"20080914203043.GA4872@lapse.rw.madduck.net","threadId":"15522","inReplyTo":null,"subject":"TopGit: how to deal with upstream inclusion","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-09-14T20:30:43Z","receivedAt":"2008-09-14T20:30:43Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Hi Petr, hi Gits,\n\nSo the Debian topgit package used to have a branch fixes/destdir to\nmake the Makefile distro-friendly. TopGit 0.3 has integrated this,\nthus obsoleting the fixes/destdir branch.\n\nI thought the way to handle this would be to simply delete the\nTopGit branch, but of course that breaks everything, e.g.:\n\nlapse:..t/topgit|debian/locations|% tg update\ntg: fatal: some dependencies are missing: fixes/destdir\n\nI now we had a recent discussion about how to remove branches, and\nthat there's basically no way to do this. In the discussion,\nupstream inclusion was listed as one of the instances when this\nwouldn't be needed, but that refers to upstream pulling/am'ing my\ncommits, not implementing the same functionality differently.\n\nHow do I retire the fixes/destdir branch? Do I manually remove the\ndependency from depending branches?\n\nThanks,\n\n-- \nmartin; (greetings from the heart of the sun.)\n \\____ echo mailto: !#^.\"<*>\"|tr \"<*> mailto:\" net@madduck\n \n\"one should never allow one's mind\n and one's foot to wander at the same time.\"\n -- edward perkins (yes, the librarian)\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"90691","messageId":"20080914210316.GJ10360@machine.or.cz","threadId":"15522","inReplyTo":"20080914203043.GA4872@lapse.rw.madduck.net","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-14T21:03:16Z","receivedAt":"2008-09-14T21:03:16Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Sun, Sep 14, 2008 at 09:30:43PM +0100, martin f krafft wrote:\n> So the Debian topgit package used to have a branch fixes/destdir to\n> make the Makefile distro-friendly. TopGit 0.3 has integrated this,\n> thus obsoleting the fixes/destdir branch.\n> \n> I thought the way to handle this would be to simply delete the\n> TopGit branch, but of course that breaks everything, e.g.:\n> \n> lapse:..t/topgit|debian/locations|% tg update\n> tg: fatal: some dependencies are missing: fixes/destdir\n> \n> I now we had a recent discussion about how to remove branches, and\n> that there's basically no way to do this. In the discussion,\n> upstream inclusion was listed as one of the instances when this\n> wouldn't be needed, but that refers to upstream pulling/am'ing my\n> commits, not implementing the same functionality differently.\n\n upstream should never pull TopGit branches! They have ugly history and\ncontain .topdeps and .topmsg junk files. That's what tg patch and\ntg export is there for. :-)\n\n If upstream applies the changes, the branch becomes unnecessary and\nthen it is ok to have some command like 'tg depend rm' to get rid of the\nbranch, since the *changes* aren't going away, thus we don't need to\ncreate any \"revert commits\", which is the real issue with the general\n'tg depend rm' command.\n\n> How do I retire the fixes/destdir branch? Do I manually remove the\n> dependency from depending branches?\n\n Almost. The real 'tg depend rm' (or maybe rather, 'tg depend fold' as\nin \"this topic branch got folded to that branch\") command would be\nslightly more complicated, I think, in order to ensure that no\nmysterious leftovers of the retired patch are lurking in your patch\ntree. Assuming\n\n\ttg depend fold RETIRED VANILLA\n\n (i) Take the RETIRED _base_ branch\n\n (ii) Merge in VANILLA\n\n (iii) Merge in RETIRED head branch with -s ours\n\n (iv) Now we have a commit that contains RETIRED topic branch, but with\nthe RETIRED's changes taken from VANILLA instead of RETIRED\n\n (v) Merge this into the base of your current branch\n\n (vi) Merge base to the head of your current branch, replacing RETIRED\nwith VANILLA (if not already there) in the .topdeps\n\n (vii) You do not have to add VANILLA if you depend on it recursively\nand ran tg update before to get it from your dependencies\n\n Maybe in your case this could be even simpler but this should be the\ngeneral process. Does that sound right?\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":"91183","messageId":"20080919170406.GA22849@lapse.rw.madduck.net","threadId":"15522","inReplyTo":"20080914210316.GJ10360@machine.or.cz","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-09-19T17:04:06Z","receivedAt":"2008-09-19T17:04:06Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Petr Baudis [2008.09.14.2203 +0100]:\n> \ttg depend fold RETIRED VANILLA\n> \n> (i) Take the RETIRED _base_ branch\n> \n> (ii) Merge in VANILLA\n> \n> (iii) Merge in RETIRED head branch with -s ours\n> \n> (iv) Now we have a commit that contains RETIRED topic branch, but with\n> the RETIRED's changes taken from VANILLA instead of RETIRED\n> \n> (v) Merge this into the base of your current branch\n> \n> (vi) Merge base to the head of your current branch, replacing RETIRED\n> with VANILLA (if not already there) in the .topdeps\n> \n> (vii) You do not have to add VANILLA if you depend on it recursively\n> and ran tg update before to get it from your dependencies\n> \n> Maybe in your case this could be even simpler but this should be the\n> general process. Does that sound right?\n\nYes, it does. One might want to consider to make the use of -s ours\nin (iiii) configurable, but otherwise that's it.\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \nall information contained in the above is false,\nfor reasons of military security.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"91227","messageId":"20080921141924.GI10360@machine.or.cz","threadId":"15522","inReplyTo":"20080919170406.GA22849@lapse.rw.madduck.net","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-21T14:19:24Z","receivedAt":"2008-09-21T14:19:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Sep 19, 2008 at 06:04:06PM +0100, martin f krafft wrote:\n> also sprach Petr Baudis [2008.09.14.2203 +0100]:\n> > (iii) Merge in RETIRED head branch with -s ours\n> \n> Yes, it does. One might want to consider to make the use of -s ours\n> in (iiii) configurable, but otherwise that's it.\n\nThat might be pretty dangerous, since then your topic branch will have\noutstanding branches of the retired branch, but they will _NOT_ be\nvisible to tg patch and others since they will be in both the base and\nhead.\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":"91357","messageId":"20080923063550.GC19084@piper.oerlikon.madduck.net","threadId":"15522","inReplyTo":"20080921141924.GI10360@machine.or.cz","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-09-23T06:35:50Z","receivedAt":"2008-09-23T06:35:50Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Petr Baudis [2008.09.21.1619 +0200]:\n> > Yes, it does. One might want to consider to make the use of -s ours\n> > in (iiii) configurable, but otherwise that's it.\n> \n> That might be pretty dangerous, since then your topic branch will have\n> outstanding branches of the retired branch, but they will _NOT_ be\n> visible to tg patch and others since they will be in both the base and\n> head.\n\nWell, but what if upstream implemented our solution slightly\ndifferently, and if it's only because they used tabs instead of\nspaces? We wouldn't want -s ours then, huh?\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"on the other hand, with the advent of msvc 5, i can claim i use\n emacs because it's smaller and more efficient.\" :-)\"\n -- darin johnson\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"91374","messageId":"20080923095528.GR10360@machine.or.cz","threadId":"15522","inReplyTo":"20080923063550.GC19084@piper.oerlikon.madduck.net","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-23T09:55:28Z","receivedAt":"2008-09-23T09:55:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Sep 23, 2008 at 08:35:50AM +0200, martin f krafft wrote:\n> also sprach Petr Baudis [2008.09.21.1619 +0200]:\n> > > Yes, it does. One might want to consider to make the use of -s ours\n> > > in (iiii) configurable, but otherwise that's it.\n> > \n> > That might be pretty dangerous, since then your topic branch will have\n> > outstanding branches of the retired branch, but they will _NOT_ be\n> > visible to tg patch and others since they will be in both the base and\n> > head.\n> \n> Well, but what if upstream implemented our solution slightly\n> differently, and if it's only because they used tabs instead of\n> spaces? We wouldn't want -s ours then, huh?\n\nYou still would want to get tabs in other patches that depended on the\nmerged one, no? Otherwise tg patch output will produce patches that do\nnot apply and tg export will change the tabs back to spaces.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"91459","messageId":"20080924112115.GA14841@piper.oerlikon.madduck.net","threadId":"15522","inReplyTo":"20080923095528.GR10360@machine.or.cz","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-09-24T11:21:15Z","receivedAt":"2008-09-24T11:21:15Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Petr Baudis [2008.09.23.1155 +0200]:\n> > Well, but what if upstream implemented our solution slightly\n> > differently, and if it's only because they used tabs instead of\n> > spaces? We wouldn't want -s ours then, huh?\n> \n> You still would want to get tabs in other patches that depended on\n> the merged one, no? Otherwise tg patch output will produce patches\n> that do not apply and tg export will change the tabs back to\n> spaces.\n\nI would want to have to resolve all dependent branches and change\nthem to use tabs, right. But since I used spaces and they used tabs,\nusing -s ours would give preference to spaces, no?\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \nthe reason the mainstream is thought of as a stream\nis because it is so shallow.\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"91480","messageId":"20080924152913.GY10360@machine.or.cz","threadId":"15522","inReplyTo":"20080924112115.GA14841@piper.oerlikon.madduck.net","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-24T15:29:13Z","receivedAt":"2008-09-24T15:29:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Sep 24, 2008 at 01:21:15PM +0200, martin f krafft wrote:\n> also sprach Petr Baudis [2008.09.23.1155 +0200]:\n> > > Well, but what if upstream implemented our solution slightly\n> > > differently, and if it's only because they used tabs instead of\n> > > spaces? We wouldn't want -s ours then, huh?\n> > \n> > You still would want to get tabs in other patches that depended on\n> > the merged one, no? Otherwise tg patch output will produce patches\n> > that do not apply and tg export will change the tabs back to\n> > spaces.\n> \n> I would want to have to resolve all dependent branches and change\n> them to use tabs, right. But since I used spaces and they used tabs,\n> using -s ours would give preference to spaces, no?\n\nPlease read again carefully :-) :\n\n> (i) Take the RETIRED _base_ branch\n>\n> (ii) Merge in VANILLA\n>\n> (iii) Merge in RETIRED head branch with -s ours\n>\n> (iv) Now we have a commit that contains RETIRED topic branch, but\n> with the RETIRED's changes taken from VANILLA instead of RETIRED\n\n-s ours keeps vanilla version.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nPeople who take cold baths never have rheumatism,\nbut they have cold baths.\n"},{"id":"91506","messageId":"20080924181315.GA25060@piper.oerlikon.madduck.net","threadId":"15522","inReplyTo":"20080924152913.GY10360@machine.or.cz","subject":"Re: TopGit: how to deal with upstream inclusion","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-09-24T18:13:15Z","receivedAt":"2008-09-24T18:13:15Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Petr Baudis [2008.09.24.1729 +0200]:\n> Please read again carefully :-) :\n\nOh. dear. Sorry.\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"}]}