{"thread":{"id":"1876","subject":"[PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","startedAt":"2005-09-20T02:25:20Z","lastAt":"2005-09-22T16:55:55Z","messageCount":8,"participants":["Pavel Roskin","Petr Baudis"],"isPatch":true,"patchVersion":1,"patchTotal":8},"messages":[{"id":"8952","messageId":"1127183120.31115.34.camel@dv","threadId":"1876","inReplyTo":null,"subject":"[PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-09-20T02:25:20Z","receivedAt":"2005-09-20T02:25:20Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Don't ever assume object type in cg-object-id.\n\nIf type is unknown in normalize_id(), make it empty so it's checked\nlater.  Check parent ID that it's a commit.\n\ndiff --git a/cg-object-id b/cg-object-id\n--- a/cg-object-id\n+++ b/cg-object-id\n@@ -24,22 +24,22 @@\n USAGE=\"cg-object-id [-p] [-t] [OBJECT_ID]\"\n \n . ${COGITO_LIB}cg-Xlib\n \n \n-# Normalize argument.  The normalized SHA1 ID is put to $normid,\n-# type is put to $type.\n+# Normalize argument.  The normalized SHA1 ID is put to $normid.\n+# If type is known, it's put to $type.\n normalize_id()\n {\n \tlocal id=\"$1\"\n+\tlocal type=\n \n \tif [ \"${id:(-1):1}\" = \"^\" ]; then\n \t\t# find first parent\n \t\tnormalize_id \"${id%^}\"\n \t\tnormid=$(git-cat-file commit \"$normid\" | \\\n \t\t\t awk '/^parent/{print $2; exit};/^$/{exit}') || exit 1\n-\t\ttype=\"commit\"\n \t\treturn\n \tfi\n \n \tif [ ! \"$id\" ] || [ \"$id\" = \"this\" ] || [ \"$id\" = \"HEAD\" ]; then\n \t\tread id < \"$_git/HEAD\"\n@@ -118,31 +118,33 @@ if [ \"$show_parent\" -a \"$show_tree\" ]; t\n \texit 1\n fi\n \n id=\"${ARGS[0]}\"\n normalize_id \"$id\"\n+[ \"$type\" ] || type=$(git-cat-file -t \"$normid\")\n+\n+if [ -z \"$show_tree\" ]; then\n+\tif [ \"$type\" != \"commit\" ]; then\n+\t\techo \"Invalid commit id: $normid\" >&2\n+\t\texit 1\n+\tfi\n+fi\n \n if [ \"$show_parent\" ]; then\n \tgit-cat-file commit \"$normid\" | awk '/^parent/{print $2};/^$/{exit}'\n \texit 0\n fi\n \n-[ \"$type\" ] || type=$(git-cat-file -t \"$normid\")\n if [ \"$show_tree\" ]; then\n \tif [ \"$type\" = \"commit\" ]; then\n \t\tnormid=$(git-cat-file commit \"$normid\" | sed -e 's/tree //;q')\n \t\ttype=$(git-cat-file -t \"$normid\")\n \tfi\n \n \tif [ \"$type\" != \"tree\" ]; then\n \t\techo \"Invalid tree id: $normid\" >&2\n \t\texit 1\n \tfi\n-else\n-\tif [ \"$type\" != \"commit\" ]; then\n-\t\techo \"Invalid commit id: $normid\" >&2\n-\t\texit 1\n-\tfi\n fi\n \n echo $normid\n \n\n-- \nRegards,\nPavel Roskin\n"},{"id":"9030","messageId":"20050921100040.GE24902@pasky.or.cz","threadId":"1876","inReplyTo":"1127183120.31115.34.camel@dv","subject":"Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-21T10:00:40Z","receivedAt":"2005-09-21T10:00:40Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 04:25:20AM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> told me that...\n> Don't ever assume object type in cg-object-id.\n> \n> If type is unknown in normalize_id(), make it empty so it's checked\n> later.  Check parent ID that it's a commit.\n\nWhy? In most of the cases, you have one pointless fork() more, and we\n\"assume\" only if it was in a parent line, and if that's not a commit,\nyou've got a *serious* problem with your database. fsck should yell you\nto death, and I don't think you could even normally commit such a\ncommit, so this should never happen. There's no point in wasting time\ntrying to handle seriously messed up database.\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":"9086","messageId":"1127359625.8074.18.camel@dv","threadId":"1876","inReplyTo":"20050921100040.GE24902@pasky.or.cz","subject":"Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-09-22T03:27:05Z","receivedAt":"2005-09-22T03:27:05Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello, Petr!\n\nOn Wed, 2005-09-21 at 12:00 +0200, Petr Baudis wrote:\n> Dear diary, on Tue, Sep 20, 2005 at 04:25:20AM CEST, I got a letter\n> where Pavel Roskin <proski@gnu.org> told me that...\n> > Don't ever assume object type in cg-object-id.\n> > \n> > If type is unknown in normalize_id(), make it empty so it's checked\n> > later.  Check parent ID that it's a commit.\n> \n> Why? In most of the cases, you have one pointless fork() more, and we\n> \"assume\" only if it was in a parent line, and if that's not a commit,\n> you've got a *serious* problem with your database. fsck should yell you\n> to death, and I don't think you could even normally commit such a\n> commit, so this should never happen. There's no point in wasting time\n> trying to handle seriously messed up database.\n\nI agree in this case.  I actually was unsure, but I decided to play safe\nafter reading this comment in cg-tag:\n\n#       This is most usually the ID of the commit to tag. Tagging \n#       other objects than commits is possible, but rather \"unusual\". \n\nAs for fsck \"yelling to death\", when was the last time you tried that on\nthe cogito repository fetched by cogito?  That's what I get:\n\n[proski@dv cogito]$ git-fsck-objects\nmissing tree 0842d4cb3cd36675c518c241b16cf25fad0c5384\nbroken link from  commit 2c70421be7d88fbee49986d7a5584d1f010a25de\n              to    tree 8c365c79293c9a8a86dc6802f6230e389e876acb\nbroken link from  commit 2c70421be7d88fbee49986d7a5584d1f010a25de\n              to  commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4\nbroken link from  commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n              to    tree 0842d4cb3cd36675c518c241b16cf25fad0c5384\nbroken link from  commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n              to  commit ed34298a39b05e05bd333d9dac658df19e5b2dab\nmissing commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4\nmissing tree 8c365c79293c9a8a86dc6802f6230e389e876acb\nmissing commit c4cd9bc72a6e0ed355041d331bb4034d99738f82\nbroken link from  commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n              to    tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9\nbroken link from  commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n              to  commit c4cd9bc72a6e0ed355041d331bb4034d99738f82\nmissing tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9\nmissing commit ed34298a39b05e05bd333d9dac658df19e5b2dab\n\n\nIt's not like broken trees are exceedingly rare.  Sure, this must be\nsome \"better\" kind of breakage, but anyway.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"9092","messageId":"20050922094643.GC21019@pasky.or.cz","threadId":"1876","inReplyTo":"1127359625.8074.18.camel@dv","subject":"Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-22T09:46:43Z","receivedAt":"2005-09-22T09:46:43Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 22, 2005 at 05:27:05AM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> told me that...\n> As for fsck \"yelling to death\", when was the last time you tried that on\n> the cogito repository fetched by cogito?  That's what I get:\n> \n> [proski@dv cogito]$ git-fsck-objects\n> missing tree 0842d4cb3cd36675c518c241b16cf25fad0c5384\n> broken link from  commit 2c70421be7d88fbee49986d7a5584d1f010a25de\n>               to    tree 8c365c79293c9a8a86dc6802f6230e389e876acb\n> broken link from  commit 2c70421be7d88fbee49986d7a5584d1f010a25de\n>               to  commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4\n> broken link from  commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n>               to    tree 0842d4cb3cd36675c518c241b16cf25fad0c5384\n> broken link from  commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n>               to  commit ed34298a39b05e05bd333d9dac658df19e5b2dab\n> missing commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4\n> missing tree 8c365c79293c9a8a86dc6802f6230e389e876acb\n> missing commit c4cd9bc72a6e0ed355041d331bb4034d99738f82\n> broken link from  commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n>               to    tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9\n> broken link from  commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n>               to  commit c4cd9bc72a6e0ed355041d331bb4034d99738f82\n> missing tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9\n> missing commit ed34298a39b05e05bd333d9dac658df19e5b2dab\n\n\nHeh, your database seems fairly broken.\n\n> It's not like broken trees are exceedingly rare.  Sure, this must be\n> some \"better\" kind of breakage, but anyway.\n\n$ git-fsck-objects\nerror: b3e9704ecdf48869f635f0aa99ddfb513f885aff: object not found\n\nand some dangling stuff, that's all I get. This seems to be caused by\nthe mere existence of that (empty) file, so I just removed it from the\nobjects database and all is fine now.\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":"9093","messageId":"20050922095257.GD21019@pasky.or.cz","threadId":"1876","inReplyTo":"20050922094643.GC21019@pasky.or.cz","subject":"Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-22T09:52:57Z","receivedAt":"2005-09-22T09:52:57Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 22, 2005 at 11:46:43AM CEST, I got a letter\nwhere Petr Baudis <pasky@suse.cz> told me that...\n> Dear diary, on Thu, Sep 22, 2005 at 05:27:05AM CEST, I got a letter\n> where Pavel Roskin <proski@gnu.org> told me that...\n> > As for fsck \"yelling to death\", when was the last time you tried that on\n> > the cogito repository fetched by cogito?  That's what I get:\n> > \n> > [proski@dv cogito]$ git-fsck-objects\n> > missing tree 0842d4cb3cd36675c518c241b16cf25fad0c5384\n> > broken link from  commit 2c70421be7d88fbee49986d7a5584d1f010a25de\n> >               to    tree 8c365c79293c9a8a86dc6802f6230e389e876acb\n> > broken link from  commit 2c70421be7d88fbee49986d7a5584d1f010a25de\n> >               to  commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4\n> > broken link from  commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n> >               to    tree 0842d4cb3cd36675c518c241b16cf25fad0c5384\n> > broken link from  commit 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n> >               to  commit ed34298a39b05e05bd333d9dac658df19e5b2dab\n> > missing commit 659bd6b6489ae254a07b1bc578ff44778ed7b8b4\n> > missing tree 8c365c79293c9a8a86dc6802f6230e389e876acb\n> > missing commit c4cd9bc72a6e0ed355041d331bb4034d99738f82\n> > broken link from  commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n> >               to    tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9\n> > broken link from  commit d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n> >               to  commit c4cd9bc72a6e0ed355041d331bb4034d99738f82\n> > missing tree e5ea614d1884a02314a3be8e09cb3f8c786fc0e9\n> > missing commit ed34298a39b05e05bd333d9dac658df19e5b2dab\n> \n> \n> Heh, your database seems fairly broken.\n\nOk, this seems like broken database on kernel.org, sorry about that. It\nactually just contained some superfluous objects. I pruned it and it\nseems that fsck is happy now.\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":"9120","messageId":"1127403479.14856.13.camel@dv","threadId":"1876","inReplyTo":"20050922094643.GC21019@pasky.or.cz","subject":"Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-09-22T15:37:59Z","receivedAt":"2005-09-22T15:37:59Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hi, Petr!\n\nOn Thu, 2005-09-22 at 11:46 +0200, Petr Baudis wrote:\n> $ git-fsck-objects\n> error: b3e9704ecdf48869f635f0aa99ddfb513f885aff: object not found\n> \n> and some dangling stuff, that's all I get. This seems to be caused by\n> the mere existence of that (empty) file, so I just removed it from the\n> objects database and all is fine now.\n\nMaybe kernel.org site is not in sync yet, but anyway, here's what I\nfound.\n\nI ran this script:\n\n[proski@dv cogito]$ for i in .git/refs/tags/*; do git-tar-tree `cat $i` >/dev/null || echo $i; done\nfatal: not a reference to a tag, commit or tree object: 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n.git/refs/tags/git-pasky-0.1\nfatal: not a reference to a tag, commit or tree object: 2c70421be7d88fbee49986d7a5584d1f010a25de\n.git/refs/tags/git-pasky-0.2\nfatal: not a reference to a tag, commit or tree object: d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n.git/refs/tags/git-pasky-0.3\n\nIf I delete the bad tags and prune the tree, git-fsck-objects has\nnothing to complain about:\n\n[proski@dv cogito]$ rm .git/refs/tags/git-pasky-0.1\n[proski@dv cogito]$ rm .git/refs/tags/git-pasky-0.2\n[proski@dv cogito]$ rm .git/refs/tags/git-pasky-0.3\n[proski@dv cogito]$ git-prune origin `cat .git/refs/tags/*`\n[proski@dv cogito]$ git-fsck-objects \n[proski@dv cogito]$\n\nThat's probably what you should do on the master tree if you haven't\ndone it.\n\nI can run \"git-prune origin\", but then cg-fetch would refetch objects\nfor more tags:\n\nMissing object of tag cogito-0.12... retrieved\nMissing object of tag cogito-0.12.1... retrieved\nMissing object of tag cogito-0.13... retrieved\nMissing object of tag cogito-0.14... retrieved\nMissing object of tag cogito-0.14.1... retrieved\nMissing object of tag cogito-0.14.2... retrieved\nMissing object of tag cogito-0.15... retrieved\nMissing object of tag git-pasky-0.1... retrieved\nMissing object of tag git-pasky-0.2... retrieved\nMissing object of tag git-pasky-0.3... retrieved\n\nHow come that cogito-0.12 - cogito-0.15 are not on the origin tree, but\nolder cogito tags are?\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"9122","messageId":"20050922155025.GK21019@pasky.or.cz","threadId":"1876","inReplyTo":"1127403479.14856.13.camel@dv","subject":"Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-22T15:50:25Z","receivedAt":"2005-09-22T15:50:25Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Sep 22, 2005 at 05:37:59PM CEST, I got a letter\nwhere Pavel Roskin <proski@gnu.org> told me that...\n> Hi, Petr!\n\nHi,\n\n> On Thu, 2005-09-22 at 11:46 +0200, Petr Baudis wrote:\n> > $ git-fsck-objects\n> > error: b3e9704ecdf48869f635f0aa99ddfb513f885aff: object not found\n> > \n> > and some dangling stuff, that's all I get. This seems to be caused by\n> > the mere existence of that (empty) file, so I just removed it from the\n> > objects database and all is fine now.\n> \n> Maybe kernel.org site is not in sync yet, but anyway, here's what I\n> found.\n\nroot      4036  2.7  2.8 106756 104080 ?     SN   00:04  14:32 rsync\n\n:/\n\n> I ran this script:\n> \n> [proski@dv cogito]$ for i in .git/refs/tags/*; do git-tar-tree `cat $i` >/dev/null || echo $i; done\n> fatal: not a reference to a tag, commit or tree object: 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n> .git/refs/tags/git-pasky-0.1\n> fatal: not a reference to a tag, commit or tree object: 2c70421be7d88fbee49986d7a5584d1f010a25de\n> .git/refs/tags/git-pasky-0.2\n> fatal: not a reference to a tag, commit or tree object: d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n> .git/refs/tags/git-pasky-0.3\n\nHuh. Huh?\n\nxpasky@machine[1:0]~/git-devel$ git-cat-file -t $(cg-object-id git-pasky-0.1)\ncommit\nxpasky@machine[1:0]~/git-devel$ git-cat-file -t $(cg-object-id git-pasky-0.2)\ncommit\nxpasky@machine[1:0]~/git-devel$ git-cat-file -t $(cg-object-id git-pasky-0.3)\ncommit\n\nSame on master.kernel.org.\n\n> I can run \"git-prune origin\", but then cg-fetch would refetch objects\n> for more tags:\n> \n> Missing object of tag cogito-0.12... retrieved\n> Missing object of tag cogito-0.12.1... retrieved\n> Missing object of tag cogito-0.13... retrieved\n> Missing object of tag cogito-0.14... retrieved\n> Missing object of tag cogito-0.14.1... retrieved\n> Missing object of tag cogito-0.14.2... retrieved\n> Missing object of tag cogito-0.15... retrieved\n> Missing object of tag git-pasky-0.1... retrieved\n> Missing object of tag git-pasky-0.2... retrieved\n> Missing object of tag git-pasky-0.3... retrieved\n> \n> How come that cogito-0.12 - cogito-0.15 are not on the origin tree, but\n> older cogito tags are?\n\nThat's because the older tags tag commits directly, not tag objects.\ngit-prune removed the tag objects because they were unreferenced by its\nperspective. Anyway, git-prune without any arguments should get it\nright.\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":"9128","messageId":"1127408155.14856.30.camel@dv","threadId":"1876","inReplyTo":"20050922155025.GK21019@pasky.or.cz","subject":"Re: [PATCH 6/8] cogito: Don't ever assume object type in cg-object-id","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2005-09-22T16:55:55Z","receivedAt":"2005-09-22T16:55:55Z","isPatch":true,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Thu, 2005-09-22 at 17:50 +0200, Petr Baudis wrote:\n> Dear diary, on Thu, Sep 22, 2005 at 05:37:59PM CEST, I got a letter\n> where Pavel Roskin <proski@gnu.org> told me that...\n> > [proski@dv cogito]$ for i in .git/refs/tags/*; do git-tar-tree `cat $i` >/dev/null || echo $i; done\n> > fatal: not a reference to a tag, commit or tree object: 463d05c7c4fe7f24da29749f4c7f25893fc20b8c\n> > .git/refs/tags/git-pasky-0.1\n> > fatal: not a reference to a tag, commit or tree object: 2c70421be7d88fbee49986d7a5584d1f010a25de\n> > .git/refs/tags/git-pasky-0.2\n> > fatal: not a reference to a tag, commit or tree object: d14925c87cdb6ca6345bcb3c8e34a2d659c79451\n> > .git/refs/tags/git-pasky-0.3\n> \n> Huh. Huh?\n> \n> xpasky@machine[1:0]~/git-devel$ git-cat-file -t $(cg-object-id git-pasky-0.1)\n> commit\n\nThe error message is misleading.  In fact, it's the tree referred to by\nthe commit that was missing.  Anyway, that object exists on the server,\nso it was my local problem.\n\nIt would be nice to have a script fetch an object by SHA1, possibly with\nthe dependencies.  git-fetch doesn't do it yet.\n\nI copied the whole objects tree for cogito using rsync, and I see lots\nor error messages from git-fsck-objects.  I'll wait for your changes to\npropagate.  As it stands now, b3e9704ecdf48869f635f0aa99ddfb513f885aff\n(a file you said you have removed) and\n11ed64c1b141c9ba397a1ca76aef2cd250976007 are still present and empty.\n\nAre you sure rsync that copies to kernel.org uses the \"delete\" option?\nIf not, we should treat kernel.org as \"dumb transport\" where directory\nlistings should never be used.\n\n> > How come that cogito-0.12 - cogito-0.15 are not on the origin tree, but\n> > older cogito tags are?\n> \n> That's because the older tags tag commits directly, not tag objects.\n> git-prune removed the tag objects because they were unreferenced by its\n> perspective. Anyway, git-prune without any arguments should get it\n> right.\n\nThanks for the explanation.  I'll be more careful with git-prune.\n\n-- \nRegards,\nPavel Roskin\n"}]}