{"thread":{"id":"14817","subject":"[ANNOUNCE] TopGit - A different patch queue manager","startedAt":"2008-08-03T03:14:24Z","lastAt":"2008-08-10T20:54:33Z","messageCount":14,"participants":["Petr Baudis","Miklos Vajna","Russell Steicke","Jon Smirl","Karl Hasselström","martin f krafft","Bert Wesarg","Sam Vilain"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"86030","messageId":"20080803031424.GV32184@machine.or.cz","threadId":"14817","inReplyTo":null,"subject":"[ANNOUNCE] TopGit - A different patch queue manager","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-03T03:14:24Z","receivedAt":"2008-08-03T03:14:24Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\n I'd like to announce TopGit v0.1, the first (while also the youngest)\nproject from my Rhine pipeline (sitting at the river shore, hacking\nfree of all online distractions; the only catch is that the offline\ndistractions can be plentiful as well - too many pretty girls tend\nto cluster around the water in the hot summer days for some strange\nreason.)\n\n TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git\nand others, of course in an attempt to Get It Right this time around.\nTopGit is absolutely minimal porcelain layer that will manage your\npatch queue for you using topic branches, one patch per branch.\nAnd do _ONLY_ that. Unlike with StGIT, you can actually use the index.\n\n TopGit aims to scratch three of my long-term patch management itches:\n\n\t(i) Let you freely specify patch dependencies, instead of\n\tforcing you to linearize your patches into a series\n\n\t(ii) Keep your development history rigorously - it is to be\n\tcleaned up only once, and that is when submitted upstream\n\n\t(iii) Actually _WORK_ in the distributed environment;\n\tyou can have several repositories and develop your patches\n\tin all of them\n\n You can get TopGit at\n\n\thttp://repo.or.cz/w/topgit.git\n\nand read up on its design, usage and implementation at:\n\n\thttp://repo.or.cz/w/topgit.git?a=blob;f=README\n\n\n This is v0.1. I started working on it last evening (by spending over\ntwo hours writing the README from scratch up to pretty much its current\nstate), got it feature complete few hours ago and testing it out the\nrest of the evening. So yes, it probably still has some bugs, but it\nshould be ready for general practical usage, so please give it a try.\nI just recreated\n\n\thttp://repo.or.cz/w/git/gitweb.git\n\nwith it and plan to use it pretty much exclusively for all my Git\npatches from now on (and it turns out there is quite a few, I just had\nno good way to organize and submit them so far).\n\n\n Besides that, some utility commands are still missing, some of them\nare TODO'd in the README. Most notably, the distributed workflow still\nhas no explicit support within TopGit which makes it a little awkward,\nand there is actually no way to mail your patches yet ;-) - tg patch\nwill only dump a single one on stdout and you need to do the rest.\n\n\n TopGit is not very well optimized so far; I made little to no\nbenchmarks and I'm focused on getting things work right first. Still,\nI believe that most operations should not take noticeably long until\nyou get into many tens of densely dependent patches. One exception\nis 'tg summary', which is unfortunately dog-slow and I couldn't\nfigure out how to speed it up further so far.\n\n\n P.S.: git/gitweb.git is mentioned here just as an example of\nreal-world TopGit usage; ignore the contents. I actually do intend\nto revive this repository, but there's still a lot of work to do.\n\n P.P.S.: Can I get trademark on the (ironically) /[^p]g/ porcelains\nnow? ;-)\n\n\n Have fun,\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":"86045","messageId":"20080803072726.GB32057@genesis.frugalware.org","threadId":"14817","inReplyTo":"20080803031424.GV32184@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit - A different patch queue manager","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-08-03T07:27:26Z","receivedAt":"2008-08-03T07:27:26Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, Aug 03, 2008 at 05:14:24AM +0200, Petr Baudis wrote:\n> \t(iii) Actually _WORK_ in the distributed environment;\n> \tyou can have several repositories and develop your patches\n> \tin all of them\n\nAs we discussed on IRC, this means that unlike git rebase -i and others,\nthe history of such rebases is not stored in reflogs (which are not\ntransfered) but stored with this \"one branch, one patch\" logic.\n\n> P.P.S.: Can I get trademark on the (ironically) /[^p]g/ porcelains\n> now? ;-)\n\nHeh, no please. I have a porcelain called 'dg'[0] after 'darcs-git', which\nimitates some of the darcs UI, but operating on a git repo. ;-)\n\n[0] http://tinyurl.com/5lfs5g, http://tinyurl.com/6pb772\n"},{"id":"86066","messageId":"20080803120201.GW10151@machine.or.cz","threadId":"14817","inReplyTo":"20080803072726.GB32057@genesis.frugalware.org","subject":"Re: [ANNOUNCE] TopGit - A different patch queue manager","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-03T12:02:01Z","receivedAt":"2008-08-03T12:02:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Aug 03, 2008 at 09:27:26AM +0200, Miklos Vajna wrote:\n> Heh, no please. I have a porcelain called 'dg'[0] after 'darcs-git', which\n> imitates some of the darcs UI, but operating on a git repo. ;-)\n> \n> [0] http://tinyurl.com/5lfs5g, http://tinyurl.com/6pb772\n\nOh, good to know. I was considering naming this 'dg' as a pun on 'cg'\n(though only half-seriously ;).\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"86073","messageId":"20080803141030.GC11179@maggie.localnet","threadId":"14817","inReplyTo":"20080803031424.GV32184@machine.or.cz","subject":"[PATCH] [TopGit] Check for pre-commit hook existence.","fromName":"Russell Steicke","fromEmail":"russellsteicke@gmail.com","sentAt":"2008-08-03T14:14:01Z","receivedAt":"2008-08-03T14:14:01Z","isPatch":true,"sender":{"key":"russellsteicke@gmail.com","avatar":null},"body":"Running tg in a repo without an active pre-commit hook fails\nsaying\n\n grep: .git/hooks/pre-commit: No such file or directory\n cat: .git/hooks/pre-commit: No such file or directory\n\nEven \"tg help\" does this! So add extra checks for existence\nof the pre-commit hook.\n\n---\n tg.sh | 10 ++++++----\n 1 files changed, 6 insertions(+), 4 deletions(-)\n\ndiff --git a/tg.sh b/tg.sh\nindex 56c5709..15005db 100644\n--- a/tg.sh\n+++ b/tg.sh\n@@ -21,9 +21,11 @@ die()\n setup_hook()\n {\n \thook_call=\"\\\"\\$(tg --hooks-path)\\\"/$1 \\\"\\$@\\\"\"\n-\tif fgrep -q \"$hook_call\" \"$git_dir/hooks/$1\"; then\n-\t\t# Another job well done!\n-\t\treturn\n+\tif [ -x \"$git_dir/hooks/$1\" ]; then\n+\t\tif fgrep -q \"$hook_call\" \"$git_dir/hooks/$1\"; then\n+\t\t\t# Another job well done!\n+\t\t\treturn\n+\t\tfi\n \tfi\n \t# Prepare incanation\n \tif [ -x \"$git_dir/hooks/$1\" ]; then\n@@ -35,7 +37,7 @@ setup_hook()\n \t{\n \t\techo \"#!/bin/sh\"\n \t\techo \"$hook_call\"\n-\t\tcat \"$git_dir/hooks/$1\"\n+\t\t[ -x \"$git_dir/hooks/$1\" ] && cat \"$git_dir/hooks/$1\"\n \t} >\"$git_dir/hooks/$1+\"\n \tchmod a+x \"$git_dir/hooks/$1+\"\n \tmv \"$git_dir/hooks/$1+\" \"$git_dir/hooks/$1\"\n-- \n1.6.0.rc1\n\n\n-- \nRussell Steicke\n\n-- Fortune says:\nI got the bill for my surgery. Now I know what those doctors were\nwearing masks for.\n\t\t-- James Boren\n"},{"id":"86075","messageId":"20080803142644.GB10151@machine.or.cz","threadId":"14817","inReplyTo":"20080803141030.GC11179@maggie.localnet","subject":"Re: [PATCH] [TopGit] Check for pre-commit hook existence.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-03T14:26:44Z","receivedAt":"2008-08-03T14:26:44Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Aug 03, 2008 at 10:14:01PM +0800, Russell Steicke wrote:\n> Running tg in a repo without an active pre-commit hook fails\n> saying\n> \n> grep: .git/hooks/pre-commit: No such file or directory\n> cat: .git/hooks/pre-commit: No such file or directory\n> \n> Even \"tg help\" does this! So add extra checks for existence\n> of the pre-commit hook.\n\nThanks, applied.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"86081","messageId":"9e4733910808030745j275eaffdib8a412fa95911bb3@mail.gmail.com","threadId":"14817","inReplyTo":"20080803031424.GV32184@machine.or.cz","subject":"Re: [ANNOUNCE] TopGit - A different patch queue manager","fromName":"Jon Smirl","fromEmail":"jonsmirl@gmail.com","sentAt":"2008-08-03T14:45:06Z","receivedAt":"2008-08-03T14:45:06Z","isPatch":false,"sender":{"key":"jonsmirl@gmail.com","avatar":"https://gravatar.com/avatar/cff3bf5bfdfa6708b905712ff91f0f9b8aaca161659f38c02b787920d5d28b7e?d=mp&s=160"},"body":"On 8/2/08, Petr Baudis wrote:\n> TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git\n> and others, of course in an attempt to Get It Right this time around.\n> TopGit is absolutely minimal porcelain layer that will manage your\n> patch queue for you using topic branches, one patch per branch.\n> And do _ONLY_ that. Unlike with StGIT, you can actually use the index.\n\nIt is very helpful to block git commands that will mess up the state\nof topgit. For example 'git rebase' is a good way to mess up stgit.\nInstead you need to do 'stg rebase'. It is quite easy to type the\nwrong command when switching between trees and some are under stgit\nand others aren't.\n\nI believe there is a stgit rewrite due any day now that completely\nchanges how it deals with the index.\n\n-- \nJon Smirl\njonsmirl@gmail.com\n"},{"id":"86180","messageId":"20080804132251.GA12255@diana.vm.bytemark.co.uk","threadId":"14817","inReplyTo":"9e4733910808030745j275eaffdib8a412fa95911bb3@mail.gmail.com","subject":"Re: [ANNOUNCE] TopGit - A different patch queue manager","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-08-04T13:22:51Z","receivedAt":"2008-08-04T13:22:51Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-08-03 10:45:06 -0400, Jon Smirl wrote:\n\n> It is very helpful to block git commands that will mess up the state\n> of topgit. For example 'git rebase' is a good way to mess up stgit.\n> Instead you need to do 'stg rebase'. It is quite easy to type the\n> wrong command when switching between trees and some are under stgit\n> and others aren't.\n\nIndeed. This is mitigated somewhat by the new \"stg undo\" command, but\nit's still perhaps StGit's largest UI wart.\n\n> I believe there is a stgit rewrite due any day now that completely\n> changes how it deals with the index.\n\nThe master branch contains an infrastructure rewrite that makes it\neasy to make the various commands handle the index nicely. A lot of\ncommands have been fixed to take advantage of it, but a bunch still\nremain.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"86425","messageId":"20080807175623.GA16833@lapse.rw.madduck.net","threadId":"14817","inReplyTo":"20080803031424.GV32184@machine.or.cz","subject":"linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2008-08-07T17:56:24Z","receivedAt":"2008-08-07T17:56:24Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"Hi Petr and everyone else,\n\nas some of you may know, I am working on http://vcs-pkg.org, and\nPierre kindly alerted me to your announcement, which looks very\ninteresting for what we are trying to do.\n\nAssuming a number of interdependent topic branches, does TopGit\nprovide a way for me to linearise/flatten/serialise these branches\nin a one-patch-per-branch fashion, so that I could turn any TopGit\nrepository into a quilt series? I am only interested in a one-way\nconversion from TopGit to quilt for now.\n\nThe reason for this is quite simply that while it's fabulous to use\ne.g. Git for managing the source repository from which to build\ndistro packages, the resulting packages will have all\ndistro-specific changes applied or collated into a single diff. This\nmakes it hard for other distributions to grab patches, for upstream\nto keep on top of what is being distributed, and for bug fixers to\nseparate patches and test only specific ones.\n\nIf we could turn a TopGit-managed forest into a quilt series, we\ncould distribute the series with the package and allow those who\ninspect the source package to use quilt to navigate the patches.\n\nIf anyone has any input on the matter, I'd love to hear it.\n\nThank you,\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 \ninfinite loop: see 'loop, infinite'.\nloop, infinite: see 'infinite loop'.\n\n\n"},{"id":"86432","messageId":"36ca99e90808071258h62b65981s20a5b053d9bc5754@mail.gmail.com","threadId":"14817","inReplyTo":"20080807175623.GA16833@lapse.rw.madduck.net","subject":"Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2008-08-07T19:58:35Z","receivedAt":"2008-08-07T19:58:35Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"Hi,\n\nOn Thu, Aug 7, 2008 at 19:56, martin f krafft wrote:\n> Hi Petr and everyone else,\n>\n> as some of you may know, I am working on http://vcs-pkg.org, and\n> Pierre kindly alerted me to your announcement, which looks very\n> interesting for what we are trying to do.\n>\n> Assuming a number of interdependent topic branches, does TopGit\n> provide a way for me to linearise/flatten/serialise these branches\n> in a one-patch-per-branch fashion, so that I could turn any TopGit\n> repository into a quilt series? I am only interested in a one-way\n> conversion from TopGit to quilt for now.\nShould be doable, I think. At least you can get a topological sorted\nlist of the TopGit branches (with git show-branch --topo-order ). But than it get complicated, because you don't\nneed the diff from branch-base to branch-head, this would only work\nfor a single dependent list of topic branches.\n\nAt least this is my current point of thinking for this problem.\n\nRegards\nBert\n> Thank you,\n"},{"id":"86529","messageId":"20080808170658.GA16055@lapse.rw.madduck.net","threadId":"14817","inReplyTo":"36ca99e90808071258h62b65981s20a5b053d9bc5754@mail.gmail.com","subject":"Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)","fromName":"martin f krafft","fromEmail":"madduck@debian.org","sentAt":"2008-08-08T17:06:58Z","receivedAt":"2008-08-08T17:06:58Z","isPatch":false,"sender":{"key":"madduck@debian.org","avatar":null},"body":"also sprach Bert Wesarg [2008.08.07.1658 -0300]:\n> Should be doable, I think. At least you can get a topological sorted\n> list of the TopGit branches (with git show-branch --topo-order of TopGit-branches>). But than it get complicated, because you don't\n> need the diff from branch-base to branch-head, this would only work\n> for a single dependent list of topic branches.\n\nHm, I am not entirely following. I understand that I can get\na topological list of branches, but why don't I need the diff from\nbranch-base to branch-head?\n\nAlso, what happens if branches cross-merge?\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 \ndon't hate yourself in the morning -- sleep till noon.\n\n\n"},{"id":"86530","messageId":"36ca99e90808081014j2c48a71bgbff3afae90259e74@mail.gmail.com","threadId":"14817","inReplyTo":"20080808170658.GA16055@lapse.rw.madduck.net","subject":"Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2008-08-08T17:14:49Z","receivedAt":"2008-08-08T17:14:49Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, Aug 8, 2008 at 19:06, martin f krafft wrote:\n> also sprach Bert Wesarg [2008.08.07.1658 -0300]:\n>> Should be doable, I think. At least you can get a topological sorted\n>> list of the TopGit branches (with git show-branch --topo-order > of TopGit-branches>). But than it get complicated, because you don't\n>> need the diff from branch-base to branch-head, this would only work\n>> for a single dependent list of topic branches.\n>\n> Hm, I am not entirely following. I understand that I can get\n> a topological list of branches, but why don't I need the diff from\n> branch-base to branch-head?\nbranch-base is a merge of all dependent branches, and if there are\nmore than one you need probably other diffs to get to this merged\nbranch, than the simple base..head of these branches.\n\n>\n> Also, what happens if branches cross-merge?\n"},{"id":"86568","messageId":"20080809010821.GT10151@machine.or.cz","threadId":"14817","inReplyTo":"20080808170658.GA16055@lapse.rw.madduck.net","subject":"Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-09T01:08:21Z","receivedAt":"2008-08-09T01:08:21Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Hi!\n\nOn Thu, Aug 07, 2008 at 02:56:24PM -0300, martin f krafft wrote:\n> Assuming a number of interdependent topic branches, does TopGit\n> provide a way for me to linearise/flatten/serialise these branches\n> in a one-patch-per-branch fashion, so that I could turn any TopGit\n> repository into a quilt series? I am only interested in a one-way\n> conversion from TopGit to quilt for now.\n\nNot _yet_. But it very well could, and it should be really simple.\n\nThere are two parts:\n\n(i) First, getting a \"tidied up\" commit structure from TopGit, having\none commit per patch (branch). This is something covered currently in\nthe README by:\n\n\tTODO: tg collapse for creating a one-commit-per-patch tidied up\n\t\thistory (for pulling by upstream)\n\nSo it's not implemented yet, but it should be *very* easy to do.\n\n(ii) Second, linearizing this commit structures to a series. This should\nbe as simple as running\n\n\tgit log --pretty=email -p --topo-order\n\non the collapsed history.\n\n> The reason for this is quite simply that while it's fabulous to use\n> e.g. Git for managing the source repository from which to build\n> distro packages, the resulting packages will have all\n> distro-specific changes applied or collated into a single diff. This\n> makes it hard for other distributions to grab patches, for upstream\n> to keep on top of what is being distributed, and for bug fixers to\n> separate patches and test only specific ones.\n\nThis is exactly what TopGit seeks to alleviate.\n\nOn Fri, Aug 08, 2008 at 02:06:58PM -0300, martin f krafft wrote:\n> Also, what happens if branches cross-merge?\n\nThis would mean there is circular dependence between the branches, which\nis invalid setup for TopGit - you could not get a linear ordering out of\nthe branches anyway; in result, each branch has to turn out to a single\nfinal Git commit - with circular dependencies, you cannot do that.\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":"86573","messageId":"1218247773.17053.32.camel@maia.lan","threadId":"14817","inReplyTo":"20080808170658.GA16055@lapse.rw.madduck.net","subject":"Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2008-08-09T02:09:33Z","receivedAt":"2008-08-09T02:09:33Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Fri, 2008-08-08 at 14:06 -0300, martin f krafft wrote:\n> Hm, I am not entirely following. I understand that I can get\n> a topological list of branches, but why don't I need the diff from\n> branch-base to branch-head?\n\nWell, if the patches can be assembled into it, why would you?\n\n> Also, what happens if branches cross-merge?\n\nNot really a problem, just need to provide a diff against one (or even\nboth) of the merge bases to the merge commit, and have it labeled as\nbeing a relatively disinteresting patch that merges X with Y.\n\nSam.\n"},{"id":"86718","messageId":"20080810205433.GF32184@machine.or.cz","threadId":"14817","inReplyTo":"20080809010821.GT10151@machine.or.cz","subject":"Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-10T20:54:33Z","receivedAt":"2008-08-10T20:54:33Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Sat, Aug 09, 2008 at 03:08:21AM +0200, Petr Baudis wrote:\n> On Thu, Aug 07, 2008 at 02:56:24PM -0300, martin f krafft wrote:\n> > Assuming a number of interdependent topic branches, does TopGit\n> > provide a way for me to linearise/flatten/serialise these branches\n> > in a one-patch-per-branch fashion, so that I could turn any TopGit\n> > repository into a quilt series? I am only interested in a one-way\n> > conversion from TopGit to quilt for now.\n> \n> Not _yet_. But it very well could, and it should be really simple.\n> \n> There are two parts:\n> \n> (i) First, getting a \"tidied up\" commit structure from TopGit, having\n> one commit per patch (branch). This is something covered currently in\n> the README by:\n> \n> \tTODO: tg collapse for creating a one-commit-per-patch tidied up\n> \t\thistory (for pulling by upstream)\n> \n> So it's not implemented yet, but it should be *very* easy to do.\n\n to prove the point, I just pushed out tg-export implementation (seems\nlike better name than collapse, for various reasons). It ended up not to\nbe as trivial as I thought, but still no more than a two-hour job. ;-)\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"}]}