{"thread":{"id":"2148","subject":"git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","startedAt":"2005-10-19T09:02:14Z","lastAt":"2005-10-20T00:43:48Z","messageCount":13,"participants":["Martin Langhoff","Junio C Hamano","Linus Torvalds","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10270","messageId":"46a038f90510190202n60101c5cgf27bd714dce00513@mail.gmail.com","threadId":"2148","inReplyTo":null,"subject":"git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-19T09:02:14Z","receivedAt":"2005-10-19T09:02:14Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/19/05, Junio C Hamano wrote:\n> Although I do not follow Cogito development closely, I seem to\n> recall that it fetched tags without making them complete at some\n> point in the past; I hope it is now fixed but I am not sure.\n\nOk -- I can now shed some light on this. This was happening on a\nDebianPPC machine, but I didn't have clear evidence of that being a\nfactor (specially when Linus is widely known to use a PPC, and I\nhadn't seen problems in other ppc boxen around). Now I do.\n\nFor all my finger-pointing, cg-fetch was trying to fetch the refernces\nproperly. However, git-fetch-pack is segfaulting on this Debian PPC\n(etch). This is true of the current git \"master\" and 0.99.8.c. I\ndon'thave strace on the box until tomorrow, so I can't tell you more\nabout it.\n\nOn Debian i386 and Ubuntu i386, the exact same versions work correctly.\n\nI'll post more info as soon as I can get my hands on strace,\n\ncheers,\n\n\n\nmartin\n"},{"id":"10273","messageId":"7v7jc9c15w.fsf@assigned-by-dhcp.cox.net","threadId":"2148","inReplyTo":"46a038f90510190202n60101c5cgf27bd714dce00513@mail.gmail.com","subject":"Re: git-send-pack segfaulting on DebianPPC","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T09:21:31Z","receivedAt":"2005-10-19T09:21:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff writes:\n\n> ... However, git-fetch-pack is segfaulting on this Debian PPC\n> (etch). This is true of the current git \"master\" and 0.99.8.c. I\n> don'thave strace on the box until tomorrow, so I can't tell you more\n> about it.\n\nThanks, that is good to know. As I said in another message, I\nlooked at cg-fetch's current tag completion code while working\non the ref^{tree} thing, and saw it used commit walker with '-a'\noption (IOW, not producing an incomplete tag) to download\neverything.\n\nEven after fetch-pack segfaulted, since it does not update any\nrefs itself (it only writes them to stdout for the wrapper to\nprocess), it should not have resulted in the repository that has\nrefs pointing at objects it does not have. In fact, it writes\nits \"SHA1 - name\" list only after seeing unpack-objects exit\nsuccessfully, that should not have resulted in a corrupt\nrepository that records incomplete refs. I suspect there is\nsomething else going on here.\n\nIn cg-fetch, fetch-pack is used only in one location, and it\ndoes not have anything to do with the tag completion code.\nPresumably that explains why removing tags did not have any\neffect, although it does not explain why removing some objects\ndid -- maybe those object files you needed to remove were\ncorrupt?\n"},{"id":"10275","messageId":"46a038f90510190307u232dd3e1u8644061e4eecb308@mail.gmail.com","threadId":"2148","inReplyTo":"7v7jc9c15w.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-pack segfaulting on DebianPPC","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-19T10:07:02Z","receivedAt":"2005-10-19T10:07:02Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/19/05, Junio C Hamano wrote:\n> Martin Langhoff writes:\n>\n> > ... However, git-fetch-pack is segfaulting on this Debian PPC\n> > (etch). This is true of the current git \"master\" and 0.99.8.c. I\n> > don'thave strace on the box until tomorrow, so I can't tell you more\n> > about it.\n>\n> Thanks, that is good to know. As I said in another message, I\n> looked at cg-fetch's current tag completion code while working\n> on the ref^{tree} thing, and saw it used commit walker with '-a'\n> option (IOW, not producing an incomplete tag) to download\n> everything.\n\nOk -- I'm at home now so I can't test it any further, but reading\ncg-fetch, it would actually be running git-ssh-fetch which was failing\n(but cogito hides STDERR). When I tried it by hand, I used\ngit-fetch-pack, which segfaulted on Debian PPC and worked on i386.\n\n> Even after fetch-pack segfaulted, since it does not update any\n> refs itself (it only writes them to stdout for the wrapper to\n> process), it should not have resulted in the repository that has\n> refs pointing at objects it does not have. In fact, it writes\n> its \"SHA1 - name\" list only after seeing unpack-objects exit\n> successfully, that should not have resulted in a corrupt\n> repository that records incomplete refs. I suspect there is\n> something else going on here.\n\nHmmm. You're right, it only spits out a list of things to retrieve...\n\n> In cg-fetch, fetch-pack is used only in one location, and it\n> does not have anything to do with the tag completion code.\n> Presumably that explains why removing tags did not have any\n> effect, although it does not explain why removing some objects\n> did -- maybe those object files you needed to remove were\n> corrupt?\n\nWell, I'll strace the execution tomorrow and let you know. The tag\nobjects, however, are there. I can reliably git-cat-file tag \nthem and they look pretty normal. The commit objects they refer to are\nmissing, though.\n\ncheers,\n\n\nmartin\n"},{"id":"10283","messageId":"Pine.LNX.4.64.0510190724000.3369@g5.osdl.org","threadId":"2148","inReplyTo":"46a038f90510190202n60101c5cgf27bd714dce00513@mail.gmail.com","subject":"Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-19T14:31:06Z","receivedAt":"2005-10-19T14:31:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 19 Oct 2005, Martin Langhoff wrote:\n> \n> On Debian i386 and Ubuntu i386, the exact same versions work correctly.\n\nInteresting.\n\nAs you say, I'm obviously testing on ppc all the time, and if \ngit-fetch-pack has problems on ppc, I haven't seen them. And I fetch a \nlot.\n\nIt might be just the repo you're using. I can't test, since I obviously \ncannot ssh into the repo you pointed at (I tried to see if you had a \ngit-daemon running, but no such luck).\n\n> I'll post more info as soon as I can get my hands on strace,\n\nEven more interesting than strace might be for you to try to run \ngit-send-pack (even on an x86) under valgrind. valgrind really is a \nwonderful tool.\n\nOne other potential issue: I'm not running debian. I've run YDL, but right \nnow the machine I use is FC4. There are likely _lots_ of library \ndifferences etc there.\n\n\t\tLinus\n"},{"id":"10299","messageId":"46a038f90510191356w56b78413p6b9fe5b67fc9ee74@mail.gmail.com","threadId":"2148","inReplyTo":"Pine.LNX.4.64.0510190724000.3369@g5.osdl.org","subject":"Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-19T20:56:35Z","receivedAt":"2005-10-19T20:56:35Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/20/05, Linus Torvalds wrote:\n> Interesting.\n>\n> As you say, I'm obviously testing on ppc all the time, and if\n> git-fetch-pack has problems on ppc, I haven't seen them. And I fetch a\n> lot.\n>\n> It might be just the repo you're using. I can't test, since I obviously\n> cannot ssh into the repo you pointed at (I tried to see if you had a\n> git-daemon running, but no such luck).\n\nOk -- I seem to be wrong in blaming PPC, so it's back to cg-fetch, and\nI think I have a patch that does the right thing.\n\nTo recap: repo is slightly broken because cg-fetch has fetched tag\nobjects, but hasn't followed them through to the commit objects they\nrefer to.\n\nInternally cg-fetch is actually using git-ssh-fetch (I misreported it\nusing git-fetch-pack), which is working correctly. However, cg-fetch\nattempts to optimize the fetch process, by not calling git-ssh-fetch\nif it has the tagobj that the ref points to. How those tag objects get\nthere without commits in the first place I don't know. So I've removed\nthe optimization and life is much better.\n\nThere is a second bug during the tag fetch. Some of the references\n(created by git-cvsimport) are multiline, and break cg-fetch. It's\nprobably a bug in git-cvsimport, but I'm fixing cg-fetch to use head\n-n1 instead of cat. I'll deal with git-cvsimport later.\n\nOn this broken-ish repo, git-fetch-pack segfaults as I've reported.\nRunning it under strace shows that it dies walking the local repo,\ntrying to find a missing commit. Unlikely that this is PPC only ;-)\n\ncheers,\n\n\n\nmartin\n"},{"id":"10302","messageId":"Pine.LNX.4.64.0510191405020.3369@g5.osdl.org","threadId":"2148","inReplyTo":"46a038f90510191356w56b78413p6b9fe5b67fc9ee74@mail.gmail.com","subject":"Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-19T21:09:55Z","receivedAt":"2005-10-19T21:09:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 20 Oct 2005, Martin Langhoff wrote:\n> \n> On this broken-ish repo, git-fetch-pack segfaults as I've reported.\n> Running it under strace shows that it dies walking the local repo,\n> trying to find a missing commit. Unlikely that this is PPC only ;-)\n\nOk, that's not horribly surprising, but it's wrong.\n\nSince I'm a lazy bastard, and couldn't necessarily re-create the right \nkind of broken repository even if I weren't, could you just enable \ncore-dumps, and run gdb on the thing and report what \"where\" says is the \ncall-chain.\n\nIt's almost certainly something that looks up an object and dereferences \nit without checking whether the object lookup succeeded or not. But if you \ncan say where the SIGSEGV happens, it will be easier to figure out where.\n\nOf course, what I really _should_ do is improve \"sparse\" to the point \nwhere I can mark functions as returning \"unsafe\" pointers, and then have \nsparse statically find all the dangerous users. I should do that anyway, \nsince it would be useful for the kernel too, but it's actually quite \nnontrivial.\n\n\t\tLinus \"being lazy is not a state of\n\t\t\tmind - it's a way of life\" Torvalds\n"},{"id":"10303","messageId":"7vzmp52oor.fsf@assigned-by-dhcp.cox.net","threadId":"2148","inReplyTo":"46a038f90510191356w56b78413p6b9fe5b67fc9ee74@mail.gmail.com","subject":"Re: git-send-pack segfaulting on DebianPPC","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-19T21:15:48Z","receivedAt":"2005-10-19T21:15:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff writes:\n\n> There is a second bug during the tag fetch. Some of the references\n> (created by git-cvsimport) are multiline, and break cg-fetch. It's\n> probably a bug in git-cvsimport, but I'm fixing cg-fetch to use head\n> -n1 instead of cat. I'll deal with git-cvsimport later.\n\nWhen you update git-cvsimport, please make the tags it generates\ngit-check-ref-format happy. The rules are:\n\n - No pathname component starting with a dot '.' (cg-fetch uses\n refs/heads/.$name-fetching to store the SHA1 it has not fully\n completed; for_each_ref() deliberately ignores path component\n that start with a dot to ignore them, probably to work this\n around).\n\n - No double-dots anywhere (ref1..ref2 notation is used on the\n command line and ref with embedded double-dots introduces\n ambiguities in parsing).\n\n - No byte with value lower than \\040 (SP) nor \\177 (DEL).\n\n - No tilde '~', caret '^' or colon ':' (the first two are used\n in extended SHA1 expressions; colon is used as src:dst\n notation in push and pull).\n\n - Not ending with a slash '/'.\n\n> On this broken-ish repo, git-fetch-pack segfaults as I've reported.\n> Running it under strace shows that it dies walking the local repo,\n> trying to find a missing commit. Unlikely that this is PPC only ;-)\n"},{"id":"10313","messageId":"20051019223743.GQ30889@pasky.or.cz","threadId":"2148","inReplyTo":"46a038f90510191356w56b78413p6b9fe5b67fc9ee74@mail.gmail.com","subject":"Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-19T22:37:43Z","receivedAt":"2005-10-19T22:37:43Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Oct 19, 2005 at 10:56:35PM CEST, I got a letter\nwhere Martin Langhoff told me that...\n> To recap: repo is slightly broken because cg-fetch has fetched tag\n> objects, but hasn't followed them through to the commit objects they\n> refer to.\n\nThat must be leftover of some old fetch, before cg-fetch got fixed wrt.\nthis issue.\n\n> Internally cg-fetch is actually using git-ssh-fetch (I misreported it\n> using git-fetch-pack), which is working correctly. However, cg-fetch\n> attempts to optimize the fetch process, by not calling git-ssh-fetch\n> if it has the tagobj that the ref points to. How those tag objects get\n> there without commits in the first place I don't know. So I've removed\n> the optimization and life is much better.\n\nThe \"optimization\" or something alike needs to be there at least for the\nuser interface, so that we can actually say what tags are we\ndownloading; besides, there can be a *lot* of tags. But I'm not sure how\nmoot will this all be after Cogito moves to the remote peeking (Real\nSoon Now, promise ;-).\n\n> There is a second bug during the tag fetch. Some of the references\n> (created by git-cvsimport) are multiline, and break cg-fetch. It's\n> probably a bug in git-cvsimport, but I'm fixing cg-fetch to use head\n> -n1 instead of cat. I'll deal with git-cvsimport later.\n\nEek. Did I miss something and are multiline refs meaningful now? If not,\nthey are pretty bad and I'd imagine other parts of Cogito would be\npretty confused about that. I'd call this a corrupted repository,\ntough. Perhaps a check should be added to fsck.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10316","messageId":"46a038f90510191623k4f1a7267m50d3bbbd6665a2a3@mail.gmail.com","threadId":"2148","inReplyTo":"20051019223743.GQ30889@pasky.or.cz","subject":"Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-19T23:23:11Z","receivedAt":"2005-10-19T23:23:11Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/20/05, Petr Baudis wrote:\n> Dear diary, on Wed, Oct 19, 2005 at 10:56:35PM CEST, I got a letter\n> where Martin Langhoff told me that...\n> > To recap: repo is slightly broken because cg-fetch has fetched tag\n> > objects, but hasn't followed them through to the commit objects they\n> > refer to.\n>\n> That must be leftover of some old fetch, before cg-fetch got fixed wrt.\n> this issue.\n\nYes, I'm trying to figure out if I can fix it...\n\n> > Internally cg-fetch is actually using git-ssh-fetch (I misreported it\n> > using git-fetch-pack), which is working correctly. However, cg-fetch\n> > attempts to optimize the fetch process, by not calling git-ssh-fetch\n> > if it has the tagobj that the ref points to. How those tag objects get\n> > there without commits in the first place I don't know. So I've removed\n> > the optimization and life is much better.\n>\n> The \"optimization\" or something alike needs to be there at least for the\n> user interface, so that we can actually say what tags are we\n> downloading; besides, there can be a *lot* of tags. But I'm not sure how\n> moot will this all be after Cogito moves to the remote peeking (Real\n> Soon Now, promise ;-).\n>\n> > There is a second bug during the tag fetch. Some of the references\n> > (created by git-cvsimport) are multiline, and break cg-fetch. It's\n> > probably a bug in git-cvsimport, but I'm fixing cg-fetch to use head\n> > -n1 instead of cat. I'll deal with git-cvsimport later.\n>\n> Eek. Did I miss something and are multiline refs meaningful now? If not,\n> they are pretty bad and I'd imagine other parts of Cogito would be\n> pretty confused about that. I'd call this a corrupted repository,\n> tough. Perhaps a check should be added to fsck.\n\nActually, all the tagsrefs have only one line, but something is going\nweird around tagid=$(cat $tag) as $tag ends up containing many\nfilenames. So I undid my initial change to \"head -n1\", and I'm trying\nto fix the loop.\n\ncheers,\n\n\nmartin\n"},{"id":"10317","messageId":"20051019235208.GR30889@pasky.or.cz","threadId":"2148","inReplyTo":"46a038f90510191623k4f1a7267m50d3bbbd6665a2a3@mail.gmail.com","subject":"Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-19T23:52:08Z","receivedAt":"2005-10-19T23:52:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 20, 2005 at 01:23:11AM CEST, I got a letter\nwhere Martin Langhoff told me that...\n> Actually, all the tagsrefs have only one line, but something is going\n> weird around tagid=$(cat $tag) as $tag ends up containing many\n> filenames. So I undid my initial change to \"head -n1\", and I'm trying\n> to fix the loop.\n\nHmm, what bash version are you using? It's enclosed in\n\n\tfor tag in *\n\nand perhaps your bash misunderstood.\n\nAnyway, this should've been quoted. I've fixed that in my tree, will\npush out soon.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10318","messageId":"7v8xwpxdef.fsf@assigned-by-dhcp.cox.net","threadId":"2148","inReplyTo":"20051019235208.GR30889@pasky.or.cz","subject":"Re: git-send-pack segfaulting on DebianPPC","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-20T00:03:52Z","receivedAt":"2005-10-20T00:03:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Hmm, what bash version are you using? It's enclosed in\n>\n> \tfor tag in *\n>\n> and perhaps your bash misunderstood.\n\nIt probably is your cat not quoting $tag, which you just fixed.\nMartin's repo has a conversion from CVS, with bunch of tags\nwhose names are like \"Foo **INVALID**\" (that's whitespace and\nasterisks).\n"},{"id":"10319","messageId":"20051020001110.GS30889@pasky.or.cz","threadId":"2148","inReplyTo":"7v8xwpxdef.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-send-pack segfaulting on DebianPPC","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-10-20T00:11:10Z","receivedAt":"2005-10-20T00:11:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Oct 20, 2005 at 02:03:52AM CEST, I got a letter\nwhere Junio C Hamano told me that...\n> Petr Baudis writes:\n> \n> > Hmm, what bash version are you using? It's enclosed in\n> >\n> > \tfor tag in *\n> >\n> > and perhaps your bash misunderstood.\n> \n> It probably is your cat not quoting $tag, which you just fixed.\n> Martin's repo has a conversion from CVS, with bunch of tags\n> whose names are like \"Foo **INVALID**\" (that's whitespace and\n> asterisks).\n\nEww. Well, I pushed out the fix.\n\nBTW (for anyone reading this), in the near future, I would like to do a\ncomplete quoting review of Cogito, since while I'm trying to be careful\nnow, it wasn't always so, especially early on. Of course, *I* would also\nlike to do many other things... *hint* *hint* ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"10322","messageId":"46a038f90510191743r22205cf5ia6e5fd624c2d4949@mail.gmail.com","threadId":"2148","inReplyTo":"20051019235208.GR30889@pasky.or.cz","subject":"Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-10-20T00:43:48Z","receivedAt":"2005-10-20T00:43:48Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 10/20/05, Petr Baudis wrote:\n> Dear diary, on Thu, Oct 20, 2005 at 01:23:11AM CEST, I got a letter\n> where Martin Langhoff told me that...\n> > Actually, all the tagsrefs have only one line, but something is going\n> > weird around tagid=$(cat $tag) as $tag ends up containing many\n> > filenames. So I undid my initial change to \"head -n1\", and I'm trying\n> > to fix the loop.\n>\n> Hmm, what bash version are you using? It's enclosed in\n>\n> for tag in *\n>\n> and perhaps your bash misunderstood.\n\nAfter a bit of head-scratching, I found out what was causing this one:\nlegacy tagnames from git-cvsimport that contain '*' in the tagname. So\n\n tagid=$(cat SOME_TAG **INVALID**)\n\ngives us some really nasty surprises.\n\ncheers,\n\n\nmartin\n"}]}