# TopGit: how to deal with upstream inclusion 9 messages from 2008-09-14 to 2008-09-24. Participants: martin f krafft, Petr Baudis. Thread: https://gitlist.dev/t/15522 ## martin f krafft, 2008-09-14 20:30 Subject: TopGit: how to deal with upstream inclusion Message-ID: <20080914203043.GA4872@lapse.rw.madduck.net> URL: https://gitlist.dev/e/20080914203043.GA4872%40lapse.rw.madduck.net ``` Hi Petr, hi Gits, So the Debian topgit package used to have a branch fixes/destdir to make the Makefile distro-friendly. TopGit 0.3 has integrated this, thus obsoleting the fixes/destdir branch. I thought the way to handle this would be to simply delete the TopGit branch, but of course that breaks everything, e.g.: lapse:..t/topgit|debian/locations|% tg update tg: fatal: some dependencies are missing: fixes/destdir I now we had a recent discussion about how to remove branches, and that there's basically no way to do this. In the discussion, upstream inclusion was listed as one of the instances when this wouldn't be needed, but that refers to upstream pulling/am'ing my commits, not implementing the same functionality differently. How do I retire the fixes/destdir branch? Do I manually remove the dependency from depending branches? Thanks, -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck "one should never allow one's mind and one's foot to wander at the same time." -- edward perkins (yes, the librarian) spamtraps: madduck.bogus@madduck.net ``` ## Petr Baudis, 2008-09-14 21:03 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080914210316.GJ10360@machine.or.cz> URL: https://gitlist.dev/e/20080914210316.GJ10360%40machine.or.cz In-Reply-To: <20080914203043.GA4872@lapse.rw.madduck.net> ``` Hi, On Sun, Sep 14, 2008 at 09:30:43PM +0100, martin f krafft wrote: > So the Debian topgit package used to have a branch fixes/destdir to > make the Makefile distro-friendly. TopGit 0.3 has integrated this, > thus obsoleting the fixes/destdir branch. > > I thought the way to handle this would be to simply delete the > TopGit branch, but of course that breaks everything, e.g.: > > lapse:..t/topgit|debian/locations|% tg update > tg: fatal: some dependencies are missing: fixes/destdir > > I now we had a recent discussion about how to remove branches, and > that there's basically no way to do this. In the discussion, > upstream inclusion was listed as one of the instances when this > wouldn't be needed, but that refers to upstream pulling/am'ing my > commits, not implementing the same functionality differently. upstream should never pull TopGit branches! They have ugly history and contain .topdeps and .topmsg junk files. That's what tg patch and tg export is there for. :-) If upstream applies the changes, the branch becomes unnecessary and then it is ok to have some command like 'tg depend rm' to get rid of the branch, since the *changes* aren't going away, thus we don't need to create any "revert commits", which is the real issue with the general 'tg depend rm' command. > How do I retire the fixes/destdir branch? Do I manually remove the > dependency from depending branches? Almost. The real 'tg depend rm' (or maybe rather, 'tg depend fold' as in "this topic branch got folded to that branch") command would be slightly more complicated, I think, in order to ensure that no mysterious leftovers of the retired patch are lurking in your patch tree. Assuming tg depend fold RETIRED VANILLA (i) Take the RETIRED _base_ branch (ii) Merge in VANILLA (iii) Merge in RETIRED head branch with -s ours (iv) Now we have a commit that contains RETIRED topic branch, but with the RETIRED's changes taken from VANILLA instead of RETIRED (v) Merge this into the base of your current branch (vi) Merge base to the head of your current branch, replacing RETIRED with VANILLA (if not already there) in the .topdeps (vii) You do not have to add VANILLA if you depend on it recursively and ran tg update before to get it from your dependencies Maybe in your case this could be even simpler but this should be the general process. Does that sound right? -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ``` ## martin f krafft, 2008-09-19 17:04 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080919170406.GA22849@lapse.rw.madduck.net> URL: https://gitlist.dev/e/20080919170406.GA22849%40lapse.rw.madduck.net In-Reply-To: <20080914210316.GJ10360@machine.or.cz> ``` also sprach Petr Baudis [2008.09.14.2203 +0100]: > tg depend fold RETIRED VANILLA > > (i) Take the RETIRED _base_ branch > > (ii) Merge in VANILLA > > (iii) Merge in RETIRED head branch with -s ours > > (iv) Now we have a commit that contains RETIRED topic branch, but with > the RETIRED's changes taken from VANILLA instead of RETIRED > > (v) Merge this into the base of your current branch > > (vi) Merge base to the head of your current branch, replacing RETIRED > with VANILLA (if not already there) in the .topdeps > > (vii) You do not have to add VANILLA if you depend on it recursively > and ran tg update before to get it from your dependencies > > Maybe in your case this could be even simpler but this should be the > general process. Does that sound right? Yes, it does. One might want to consider to make the use of -s ours in (iiii) configurable, but otherwise that's it. -- martin | http://madduck.net/ | http://two.sentenc.es/ all information contained in the above is false, for reasons of military security. spamtraps: madduck.bogus@madduck.net ``` ## Petr Baudis, 2008-09-21 14:19 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080921141924.GI10360@machine.or.cz> URL: https://gitlist.dev/e/20080921141924.GI10360%40machine.or.cz In-Reply-To: <20080919170406.GA22849@lapse.rw.madduck.net> ``` On Fri, Sep 19, 2008 at 06:04:06PM +0100, martin f krafft wrote: > also sprach Petr Baudis [2008.09.14.2203 +0100]: > > (iii) Merge in RETIRED head branch with -s ours > > Yes, it does. One might want to consider to make the use of -s ours > in (iiii) configurable, but otherwise that's it. That might be pretty dangerous, since then your topic branch will have outstanding branches of the retired branch, but they will _NOT_ be visible to tg patch and others since they will be in both the base and head. -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates ``` ## martin f krafft, 2008-09-23 06:35 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080923063550.GC19084@piper.oerlikon.madduck.net> URL: https://gitlist.dev/e/20080923063550.GC19084%40piper.oerlikon.madduck.net In-Reply-To: <20080921141924.GI10360@machine.or.cz> ``` also sprach Petr Baudis [2008.09.21.1619 +0200]: > > Yes, it does. One might want to consider to make the use of -s ours > > in (iiii) configurable, but otherwise that's it. > > That might be pretty dangerous, since then your topic branch will have > outstanding branches of the retired branch, but they will _NOT_ be > visible to tg patch and others since they will be in both the base and > head. Well, but what if upstream implemented our solution slightly differently, and if it's only because they used tabs instead of spaces? We wouldn't want -s ours then, huh? -- martin | http://madduck.net/ | http://two.sentenc.es/ "on the other hand, with the advent of msvc 5, i can claim i use emacs because it's smaller and more efficient." :-)" -- darin johnson spamtraps: madduck.bogus@madduck.net ``` ## Petr Baudis, 2008-09-23 09:55 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080923095528.GR10360@machine.or.cz> URL: https://gitlist.dev/e/20080923095528.GR10360%40machine.or.cz In-Reply-To: <20080923063550.GC19084@piper.oerlikon.madduck.net> ``` On Tue, Sep 23, 2008 at 08:35:50AM +0200, martin f krafft wrote: > also sprach Petr Baudis [2008.09.21.1619 +0200]: > > > Yes, it does. One might want to consider to make the use of -s ours > > > in (iiii) configurable, but otherwise that's it. > > > > That might be pretty dangerous, since then your topic branch will have > > outstanding branches of the retired branch, but they will _NOT_ be > > visible to tg patch and others since they will be in both the base and > > head. > > Well, but what if upstream implemented our solution slightly > differently, and if it's only because they used tabs instead of > spaces? We wouldn't want -s ours then, huh? You still would want to get tabs in other patches that depended on the merged one, no? Otherwise tg patch output will produce patches that do not apply and tg export will change the tabs back to spaces. Petr "Pasky" Baudis ``` ## martin f krafft, 2008-09-24 11:21 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080924112115.GA14841@piper.oerlikon.madduck.net> URL: https://gitlist.dev/e/20080924112115.GA14841%40piper.oerlikon.madduck.net In-Reply-To: <20080923095528.GR10360@machine.or.cz> ``` also sprach Petr Baudis [2008.09.23.1155 +0200]: > > Well, but what if upstream implemented our solution slightly > > differently, and if it's only because they used tabs instead of > > spaces? We wouldn't want -s ours then, huh? > > You still would want to get tabs in other patches that depended on > the merged one, no? Otherwise tg patch output will produce patches > that do not apply and tg export will change the tabs back to > spaces. I would want to have to resolve all dependent branches and change them to use tabs, right. But since I used spaces and they used tabs, using -s ours would give preference to spaces, no? -- martin | http://madduck.net/ | http://two.sentenc.es/ the reason the mainstream is thought of as a stream is because it is so shallow. spamtraps: madduck.bogus@madduck.net ``` ## Petr Baudis, 2008-09-24 15:29 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080924152913.GY10360@machine.or.cz> URL: https://gitlist.dev/e/20080924152913.GY10360%40machine.or.cz In-Reply-To: <20080924112115.GA14841@piper.oerlikon.madduck.net> ``` On Wed, Sep 24, 2008 at 01:21:15PM +0200, martin f krafft wrote: > also sprach Petr Baudis [2008.09.23.1155 +0200]: > > > Well, but what if upstream implemented our solution slightly > > > differently, and if it's only because they used tabs instead of > > > spaces? We wouldn't want -s ours then, huh? > > > > You still would want to get tabs in other patches that depended on > > the merged one, no? Otherwise tg patch output will produce patches > > that do not apply and tg export will change the tabs back to > > spaces. > > I would want to have to resolve all dependent branches and change > them to use tabs, right. But since I used spaces and they used tabs, > using -s ours would give preference to spaces, no? Please read again carefully :-) : > (i) Take the RETIRED _base_ branch > > (ii) Merge in VANILLA > > (iii) Merge in RETIRED head branch with -s ours > > (iv) Now we have a commit that contains RETIRED topic branch, but > with the RETIRED's changes taken from VANILLA instead of RETIRED -s ours keeps vanilla version. -- Petr "Pasky" Baudis People who take cold baths never have rheumatism, but they have cold baths. ``` ## martin f krafft, 2008-09-24 18:13 Subject: Re: TopGit: how to deal with upstream inclusion Message-ID: <20080924181315.GA25060@piper.oerlikon.madduck.net> URL: https://gitlist.dev/e/20080924181315.GA25060%40piper.oerlikon.madduck.net In-Reply-To: <20080924152913.GY10360@machine.or.cz> ``` also sprach Petr Baudis [2008.09.24.1729 +0200]: > Please read again carefully :-) : Oh. dear. Sorry. -- martin | http://madduck.net/ | http://two.sentenc.es/ "i worked myself up from nothing to a state of extreme poverty." -- groucho marx spamtraps: madduck.bogus@madduck.net ```