{"thread":{"id":"1462","subject":"cg-clone http://www.kernel.org/pub/scm/git/git.git fails","startedAt":"2005-08-09T16:06:10Z","lastAt":"2005-08-12T15:37:37Z","messageCount":11,"participants":["Dirk Behme","Petr Baudis","Junio C Hamano","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6995","messageId":"42F8D472.3080404@de.bosch.com","threadId":"1462","inReplyTo":null,"subject":"cg-clone http://www.kernel.org/pub/scm/git/git.git fails","fromName":"Dirk Behme","fromEmail":"dirk.behme@de.bosch.com","sentAt":"2005-08-09T16:06:10Z","receivedAt":"2005-08-09T16:06:10Z","isPatch":false,"sender":{"key":"dirk.behme@de.bosch.com","avatar":null},"body":"Hello,\n\nwith\n\ncogito-0.13.tar.bz2\ngit-2005-08-09.tar.gz\n\nclone of cogito over http\n\n > cg-clone http://www.kernel.org/pub/scm/cogito/cogito.git\n\nworks fine. But clone of git itself fails:\n\n> cg-clone http://www.kernel.org/pub/scm/git/git.git \ndefaulting to local storage area\nwarning: templates not found /home/user/share/git-core/templates/\n16:29:03 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master\n[41/41] -> \"refs/heads/origin\" [1]\nprogress: 3 objects, 5158 bytes\nGetting pack list\nerror: Unable to get pack index\nhttp://www.kernel.org/pub/scm/git/git.git//objects/info/packs\nerror: Tried\nhttp://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3\nCannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3\nwhile processing commit adee7bdf504120055b0f36b4918bdd3e6156912b.\ncg-pull: objects pull failed\ncg-clone: pull failed\n\nIs this a tool or repository issue?\n\nMany thanks\n\nDirk\n"},{"id":"7086","messageId":"20050811223349.GI25280@pasky.ji.cz","threadId":"1462","inReplyTo":"42F8D472.3080404@de.bosch.com","subject":"git-http-pull broken in latest git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-08-11T22:33:49Z","receivedAt":"2005-08-11T22:33:49Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Aug 09, 2005 at 06:06:10PM CEST, I got a letter\nwhere Dirk Behme <dirk.behme@de.bosch.com> told me that...\n> Hello,\n\nHello,\n\n> >cg-clone http://www.kernel.org/pub/scm/git/git.git \n> defaulting to local storage area\n> warning: templates not found /home/user/share/git-core/templates/\n> 16:29:03 URL:http://www.kernel.org/pub/scm/git/git.git/refs/heads/master\n> [41/41] -> \"refs/heads/origin\" [1]\n> progress: 3 objects, 5158 bytes\n> Getting pack list\n> error: Unable to get pack index\n> http://www.kernel.org/pub/scm/git/git.git//objects/info/packs\n> error: Tried\n> http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3\n> Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3\n> while processing commit adee7bdf504120055b0f36b4918bdd3e6156912b.\n> cg-pull: objects pull failed\n> cg-clone: pull failed\n> \n> Is this a tool or repository issue?\n\nit appears that git-http-pull is broken. It gives me a different error\nnow and with the latest git, though. When using just core git:\n\n$ wget http://www.kernel.org/pub/scm/git/git.git/refs/heads/master\n$ mv master .git/refs/heads/\n$ cat .git/refs/heads/master\nbf570303153902ec3d85570ed24515bcf8948848\n$ git-http-pull -a -v $(cat .git/refs/heads/master) \\\n\thttp://www.kernel.org/pub/scm/git/git.git/\nGetting pack list\nGetting index for pack 3c5133604508466855453f3e609428f4bbba9131\nGetting index for pack 37cba29d3df65b160afabe769470f7857f98d729\nGetting pack 37cba29d3df65b160afabe769470f7857f98d729\n which contains bf570303153902ec3d85570ed24515bcf8948848\n$ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree\ntree 41f10531f1799bbb31a1e0f7652363154ce96f45\n$ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45\nfatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45\n\nKaboom. I think the issue might be that the reference dependency tree\nbuilding is broken and it should've pulled the other pack as well.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"7090","messageId":"7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net","threadId":"1462","inReplyTo":"20050811223349.GI25280@pasky.ji.cz","subject":"Re: git-http-pull broken in latest git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-11T23:21:46Z","receivedAt":"2005-08-11T23:21:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree\n> tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45\n\n> Kaboom. I think the issue might be that the reference dependency tree\n> building is broken and it should've pulled the other pack as well.\n\nLast time I checked, git-http-pull did not utilize the pack\ndependency information, which indeed is wrong.  When it decides\nto fetch a pack instead of an asked-for object, it should check\nwhich commits the pack expects to have in your local repository\nand add them to its list of things to slurp.\n\nA good news is that \"git clone\" as a whole works fine.\n\n    prompt$ cd /var/tmp/\n    prompt$ rm -fr junk\n    prompt$ git clone http://www.kernel.org/pub/scm/git/git.git junk\n    defaulting to local storage area\n    prompt$ cd junk\n    prompt$ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 |\n            grep tree\n    tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n    prompt$ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n    prompt$ /bin/ls .git/objects/pack\n    pack-37cba29d3df65b160afabe769470f7857f98d729.idx\n    pack-37cba29d3df65b160afabe769470f7857f98d729.pack\n    pack-3c5133604508466855453f3e609428f4bbba9131.idx\n    pack-3c5133604508466855453f3e609428f4bbba9131.pack\n    prompt$ \n"},{"id":"7092","messageId":"Pine.LNX.4.63.0508111929010.12816@iabervon.org","threadId":"1462","inReplyTo":"7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Re: git-http-pull broken in latest git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-11T23:38:09Z","receivedAt":"2005-08-11T23:38:09Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 11 Aug 2005, Junio C Hamano wrote:\n\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree\n> > tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> > fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45\n> \n> > Kaboom. I think the issue might be that the reference dependency tree\n> > building is broken and it should've pulled the other pack as well.\n> \n> Last time I checked, git-http-pull did not utilize the pack\n> dependency information, which indeed is wrong. \n\nIs there documentation on the format?\n\n> When it decides to fetch a pack instead of an asked-for object, it \n> should check which commits the pack expects to have in your local \n> repository and add them to its list of things to slurp.\n\nIt should work anyway, except that I messed up some logic in the parallel \npull stuff; when it finds it has something already, it ignores it \nentirely, rather than processing it. The following patch fixes this.\n---\n[PATCH] Fix parallel pull dependancy tracking.\n\nIt didn't refetch an object it already had (good), but didn't process\nit, either (bad). Synchronously process anything you already have.\n\nSigned-off-by: Daniel Barkalow <barkalow@iabervon.org>\n---\n\n pull.c |   57 ++++++++++++++++++++++++++++++++-------------------------\n 1 files changed, 32 insertions(+), 25 deletions(-)\n\n9b6b4b259c6b00d5b2502c158bc800d7623352bc\ndiff --git a/pull.c b/pull.c\n--- a/pull.c\n+++ b/pull.c\n@@ -98,12 +98,38 @@ static int process_tag(struct tag *tag)\n static struct object_list *process_queue = NULL;\n static struct object_list **process_queue_end = &process_queue;\n \n-static int process(unsigned char *sha1, const char *type)\n+static int process_object(struct object *obj)\n {\n-\tstruct object *obj;\n-\tif (has_sha1_file(sha1))\n+\tif (obj->type == commit_type) {\n+\t\tif (process_commit((struct commit *)obj))\n+\t\t\treturn -1;\n+\t\treturn 0;\n+\t}\n+\tif (obj->type == tree_type) {\n+\t\tif (process_tree((struct tree *)obj))\n+\t\t\treturn -1;\n \t\treturn 0;\n-\tobj = lookup_object_type(sha1, type);\n+\t}\n+\tif (obj->type == blob_type) {\n+\t\treturn 0;\n+\t}\n+\tif (obj->type == tag_type) {\n+\t\tif (process_tag((struct tag *)obj))\n+\t\t\treturn -1;\n+\t\treturn 0;\n+\t}\n+\treturn error(\"Unable to determine requirements \"\n+\t\t     \"of type %s for %s\",\n+\t\t     obj->type, sha1_to_hex(obj->sha1));\n+}\n+\n+static int process(unsigned char *sha1, const char *type)\n+{\n+\tstruct object *obj = lookup_object_type(sha1, type);\n+\tif (has_sha1_file(sha1)) {\n+\t\t/* We already have it, so we should scan it now. */\n+\t\treturn process_object(obj);\n+\t}\n \tif (object_list_contains(process_queue, obj))\n \t\treturn 0;\n \tobject_list_insert(obj, process_queue_end);\n@@ -134,27 +160,8 @@ static int loop(void)\n \t\t\treturn -1;\n \t\tif (!obj->type)\n \t\t\tparse_object(obj->sha1);\n-\t\tif (obj->type == commit_type) {\n-\t\t\tif (process_commit((struct commit *)obj))\n-\t\t\t\treturn -1;\n-\t\t\tcontinue;\n-\t\t}\n-\t\tif (obj->type == tree_type) {\n-\t\t\tif (process_tree((struct tree *)obj))\n-\t\t\t\treturn -1;\n-\t\t\tcontinue;\n-\t\t}\n-\t\tif (obj->type == blob_type) {\n-\t\t\tcontinue;\n-\t\t}\n-\t\tif (obj->type == tag_type) {\n-\t\t\tif (process_tag((struct tag *)obj))\n-\t\t\t\treturn -1;\n-\t\t\tcontinue;\n-\t\t}\n-\t\treturn error(\"Unable to determine requirements \"\n-\t\t\t     \"of type %s for %s\",\n-\t\t\t     obj->type, sha1_to_hex(obj->sha1));\n+\t\tif (process_object(obj))\n+\t\t\treturn -1;\n \t}\n \treturn 0;\n }\n"},{"id":"7093","messageId":"7voe84c9in.fsf@assigned-by-dhcp.cox.net","threadId":"1462","inReplyTo":"7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-http-pull broken in latest git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-11T23:57:04Z","receivedAt":"2005-08-11T23:57:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> Last time I checked, git-http-pull did not utilize the pack\n> dependency information, which indeed is wrong.  When it decides\n> to fetch a pack instead of an asked-for object, it should check\n> which commits the pack expects to have in your local repository\n> and add them to its list of things to slurp.\n\nOh, well, the above makes it sound as if I am blaming Daniel for\nthis, but the blame lies on me who did not document properly\nwhat is going on, in except the comments in the source.  So here\nis an explanation.\n\nA $GIT_DIR/objects/info/packs file looks like this:\n\n    P pack-3c5133604508466855453f3e609428f4bbba9131.pack\n    P pack-37cba29d3df65b160afabe769470f7857f98d729.pack\n    D 0\n    D 1 0\n    T 0 c1c774e7965ba08061c3fc7bc57aebc7eeb6b40f commit\n    T 0 d6602ec5194c87b0fc87103ca4d67251c76f233a tag\n    T 1 0918385dbd9656cab0d1d81ba7453d49bbc16250 tag\n    T 1 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e tag\n    T 1 b3e9704ecdf48869f635f0aa99ddfb513f885aff tag\n    T 1 c5db5456ae3b0873fc659c19fafdde22313cc441 tag\n    T 1 f25a265a342aed6041ab0cc484224d9ca54b6f41 tag\n\nP lines are list of packs, and they are implicitly numbered\nstarting from #0.  3c5133 pack is pack #0 and 37cba2 pack is\npack #1 in the above example.\n\nD lines are pack dependencies.  \"D 0\" says pack #0 does not\ndepend on any, \"D 1 0\" says pack #1 depends on pack #0.\n\nT lines are what I call \"pack edges\".  They are objects that are\nnot reachable from any other object contained in the same pack.\nWhat this means is that if you have all of the listed objects\nfor a pack, downloading that pack is useless for you.  This of\ncourse requires that your local repository is not partial.\n\nA D line says that pack #1 depends on pack #0.  So if you decide\nto slurp pack #1 because you wanted to have one object that is\nnot available as a plain file under objects/??/, you had better\nmake sure that you have all the objects available in pack #0.\n\nOne way to do so is to look at T lines for pack #0 and make sure\nyou have those \"pack edge\" objects in the local repository.  If\nyou discover you do not have them, you either need to slurp pack\n#0 as well, or start walking the commits from these pack edges.\nIf http-pull slurped pack #0, which does not depend on anything\nelse, this would obviously complete the process.  However, even\nif http-pull chose to walk the commits, if the remote repository\nis fully packed, it would end up slurping pack #0.  So either\nway would work fine in theory, and the choice of which approach\nto take really depends on \"which one is more efficient\".\n\nThe only case when walking the commits from pack edges could be\na win is when your local repository have most but not all of the\nobjects that are in pack #0 on the remote side, and the remote\nside has those needed objects lying around unpacked, in addition\nto having them in the pack #0.  This is very unlikely because\n(1) the remote side says pack #1 depends on pack #0, which means\npack #0 is older than pack #1, and (2) we ended up slurping pack\n#1, which means objects in pack #1 have already been removed by\n\"git prune-packed\" on the remote side.  These two makes it very\nlikely that objects in pack #0 are already prune-packed on the\nremote side.  So my recommendation is to just slurp the depended\non pack, pack #0, in this case instead of adding the pack edge\nobjects to \"to be commit-walked\" list.\n"},{"id":"7099","messageId":"7vzmrnc3qt.fsf@assigned-by-dhcp.cox.net","threadId":"1462","inReplyTo":"Pine.LNX.4.63.0508111929010.12816@iabervon.org","subject":"Re: [PATCH] Re: git-http-pull broken in latest git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-12T02:01:46Z","receivedAt":"2005-08-12T02:01:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> It should work anyway,...\n\nThat is true.  Please forget about the \"recommendation\" to slurp\npacks and not falling back on commit walker.\n\nThanks for the patch.\n"},{"id":"7100","messageId":"Pine.LNX.4.63.0508112211080.12816@iabervon.org","threadId":"1462","inReplyTo":"7vzmrnc3qt.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Re: git-http-pull broken in latest git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-12T02:12:38Z","receivedAt":"2005-08-12T02:12:38Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 11 Aug 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > It should work anyway,...\n> \n> That is true.  Please forget about the \"recommendation\" to slurp\n> packs and not falling back on commit walker.\n> \n> Thanks for the patch.\n\nNo problem; I had been wondering what the rest of those lines were about \nanyway.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7101","messageId":"20050812024552.GO25280@pasky.ji.cz","threadId":"1462","inReplyTo":"7v4q9wf4ad.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-http-pull broken in latest git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-08-12T02:45:52Z","receivedAt":"2005-08-12T02:45:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Aug 12, 2005 at 01:21:46AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree\n> > tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> > fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45\n> \n> > Kaboom. I think the issue might be that the reference dependency tree\n> > building is broken and it should've pulled the other pack as well.\n> \n> Last time I checked, git-http-pull did not utilize the pack\n> dependency information, which indeed is wrong.  When it decides\n> to fetch a pack instead of an asked-for object, it should check\n> which commits the pack expects to have in your local repository\n> and add them to its list of things to slurp.\n> \n> A good news is that \"git clone\" as a whole works fine.\n\nYes, but cg-clone doesn't - it naively depended on the core git tools\nactually, er.. working. ;-)\n\nThis became a nightmare to me by now - on two machines I tried to pull\nto over HTTP, that failed miserably, and I got stuck until I applied\nDaniel's patch there (and cleaned up after previous git-http-pulls).\n\nSo I have this packless git-pb repository and suspecting no evil, I pull\nfrom you (thankfully I have .git/objects/pack there from some historical\npulls). I do a merge commit:\n\n\tpacked\n\t ... J\n\tpacked \\\n\t\t > M\n\t       /\n\t ... P\n\nNow I want to pull on another machine. That pulls M and then fails since\nI have no .git/objects/pack there, bummer. So I mkdir it, but get no\nfurther w/o Daniel's patch - for git-*-pull, J is missing and that's it.\nSo I apply the patch, and get friendly\n\n\terror: Unable to determine requirements of type (null) for M\n\nand only after I delete M from the database, I finally succeed with\ngit-http-pull. (That was with --repair.) That's not good since this\nmight occur even naturally when the pull is interrupted.\n\nWith git-ssh-pull, the situation is even more vexing - it refuses to\nfetch the packs for some reason yet unknown to me (I will debug it\ntomorrow).\n\nThe git-*-pull tools appear yet rather fragile. :/\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"7102","messageId":"Pine.LNX.4.63.0508112256430.12816@iabervon.org","threadId":"1462","inReplyTo":"20050812024552.GO25280@pasky.ji.cz","subject":"[PATCH] Re: git-http-pull broken in latest git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-12T03:17:55Z","receivedAt":"2005-08-12T03:17:55Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 12 Aug 2005, Petr Baudis wrote:\n\n> Dear diary, on Fri, Aug 12, 2005 at 01:21:46AM CEST, I got a letter\n> where Junio C Hamano <junkio@cox.net> told me that...\n> > Petr Baudis <pasky@suse.cz> writes:\n> > \n> > > $ git-cat-file commit bf570303153902ec3d85570ed24515bcf8948848 | grep tree\n> > > tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> > > $ git-read-tree 41f10531f1799bbb31a1e0f7652363154ce96f45\n> > > fatal: failed to unpack tree object 41f10531f1799bbb31a1e0f7652363154ce96f45\n> > \n> > > Kaboom. I think the issue might be that the reference dependency tree\n> > > building is broken and it should've pulled the other pack as well.\n> > \n> > Last time I checked, git-http-pull did not utilize the pack\n> > dependency information, which indeed is wrong.  When it decides\n> > to fetch a pack instead of an asked-for object, it should check\n> > which commits the pack expects to have in your local repository\n> > and add them to its list of things to slurp.\n> > \n> > A good news is that \"git clone\" as a whole works fine.\n> \n> Yes, but cg-clone doesn't - it naively depended on the core git tools\n> actually, er.. working. ;-)\n> \n> This became a nightmare to me by now - on two machines I tried to pull\n> to over HTTP, that failed miserably, and I got stuck until I applied\n> Daniel's patch there (and cleaned up after previous git-http-pulls).\n> \n> So I have this packless git-pb repository and suspecting no evil, I pull\n> from you (thankfully I have .git/objects/pack there from some historical\n> pulls). I do a merge commit:\n> \n> \tpacked\n> \t ... J\n> \tpacked \\\n> \t\t > M\n> \t       /\n> \t ... P\n> \n> Now I want to pull on another machine. That pulls M and then fails since\n> I have no .git/objects/pack there, bummer. So I mkdir it, but get no\n> further w/o Daniel's patch - for git-*-pull, J is missing and that's it.\n> So I apply the patch, and get friendly\n> \n> \terror: Unable to determine requirements of type (null) for M\n> \n> and only after I delete M from the database, I finally succeed with\n> git-http-pull. (That was with --repair.) That's not good since this\n> might occur even naturally when the pull is interrupted.\n\nInsufficient testing on my part; patch at the end.\n\n> With git-ssh-pull, the situation is even more vexing - it refuses to\n> fetch the packs for some reason yet unknown to me (I will debug it\n> tomorrow).\n\ngit-ssh-pull doesn't deal in packs; it gets individual objects out of \npacks, which git-ssh-push (on the remote side) should be extracting. \nPerhaps you have a git-ssh-push on the remote side that's before I make \npacks work (it used to need to have the files for objects it was sending). \n\nAt some point, I have to revisit getting git-ssh-* to generate exactly the \nrequired pack and transfer that, but that's an efficiency issue, not a \ncorrectness one, and shouldn't be relevant to the problem you're having.\n\n---\n[PATCH] Also parse objects we already have\n\nIn the case where we don't know from context what type an object is, but\nwe don't have to fetch it, we need to parse it to determine the type\nbefore processing it.\n\nSigned-off-by: Daniel Barkalow <barkalow@iabervon.org>\n---\n\n pull.c |    1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\nb8c382e76da25f45ff86176a6a6affdd9a28d60b\ndiff --git a/pull.c b/pull.c\n--- a/pull.c\n+++ b/pull.c\n@@ -127,6 +127,7 @@ static int process(unsigned char *sha1, \n {\n \tstruct object *obj = lookup_object_type(sha1, type);\n \tif (has_sha1_file(sha1)) {\n+\t\tparse_object(sha1);\n \t\t/* We already have it, so we should scan it now. */\n \t\treturn process_object(obj);\n \t}\n"},{"id":"7104","messageId":"7vll37afz4.fsf@assigned-by-dhcp.cox.net","threadId":"1462","inReplyTo":"Pine.LNX.4.63.0508112256430.12816@iabervon.org","subject":"Re: [PATCH] Re: git-http-pull broken in latest git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-12T05:20:31Z","receivedAt":"2005-08-12T05:20:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> Petr Baudis <pasky@suse.cz> writes:\n>> Yes, but cg-clone doesn't - it naively depended on the core git tools\n>> actually, er.. working. ;-)\n\nSorry about that.  I used to have a wrapper to deal with packs\naround http-pull before Daniel's pack enhancement, and yanking\nit before really checking that enhanced http-pull actually\nworked was my fault as well.\n\n>> This became a nightmare to me by now - on two machines I tried to pull\n>> to over HTTP, that failed miserably, and I got stuck until I applied\n>> Daniel's patch there (and cleaned up after previous git-http-pulls).\n\nI'll push one out with two patches from Daniel today in short\norder.  Currently running the final \"make test\" round.\n\n> At some point, I have to revisit getting git-ssh-* to generate exactly the \n> required pack and transfer that, but that's an efficiency issue, not a \n> correctness one, and shouldn't be relevant to the problem you're having.\n\nWouldn't enhancing ssh-push to generate packs on the fly involve\nreinventing send-pack and/or upload-pack?\n\nIf send-pack/receive-pack pair for the push side, and/or\nfetch&clone-pack/upload-pack pair for the pull side does not\nwork as well as you would want, then ssh-push/pull pair may\nstill be a useful tool, at the same time that means send-pack\nand upload-pack should be fixed to address the problem you have\nwith them.  But if that is not the case, then it might be better\nto declare that ssh-pull/push pair has outlived its usefulness.\n\nThe same thing can be said about local-pull to a lesser degree.\nLesser because people, including Pasky who said so on the list\nrecently, would like its hard-linking behaviour, and its not\nexploding the existing packs, which send-pack and upload-pack\nwould not give.  So I would rate local-pull higher than\nssh-push/pull on the priority scale if I were doing them.\n"},{"id":"7121","messageId":"Pine.LNX.4.63.0508121111070.12816@iabervon.org","threadId":"1462","inReplyTo":"7vll37afz4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Re: git-http-pull broken in latest git","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-12T15:37:37Z","receivedAt":"2005-08-12T15:37:37Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 11 Aug 2005, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > Petr Baudis <pasky@suse.cz> writes:\n> >> Yes, but cg-clone doesn't - it naively depended on the core git tools\n> >> actually, er.. working. ;-)\n> \n> Sorry about that.  I used to have a wrapper to deal with packs\n> around http-pull before Daniel's pack enhancement, and yanking\n> it before really checking that enhanced http-pull actually\n> worked was my fault as well.\n\nIt was actually the patches after the http-pull fixes (the ones for \nparallelizing pull.c) that broke things; one advantage to fixing \nlocal-pull would be that you can set up tests for it reasonably \neffectively, which would have caught the regression.\n\n> > At some point, I have to revisit getting git-ssh-* to generate exactly the \n> > required pack and transfer that, but that's an efficiency issue, not a \n> > correctness one, and shouldn't be relevant to the problem you're having.\n> \n> Wouldn't enhancing ssh-push to generate packs on the fly involve\n> reinventing send-pack and/or upload-pack?\n\nThe idea is that you wouldn't have to identify what situation applied \nyourself; you could just invoke git-ssh-pull/git-ssh-push, and it would \nhappen faster due to the compression benefits. The point is that scripts \ncan just pick which git-*-pull to use based on the format of the remote \nbranch address, without variation in behavior.\n\n> The same thing can be said about local-pull to a lesser degree.\n> Lesser because people, including Pasky who said so on the list\n> recently, would like its hard-linking behaviour, and its not\n> exploding the existing packs, which send-pack and upload-pack\n> would not give.  So I would rate local-pull higher than\n> ssh-push/pull on the priority scale if I were doing them.\n\nThis is a higher priority, but writing more than bugfixes is unpleasent at \nthe moment due to my home workstation's monitor dying, so it'll probably \nbe next week that I'll get to it. The git-ssh-* stuff is longer-term, \nsince it works now, and isn't even all that slow with the overlapping \nrequests.\n\nYou could, actually, probably do the local-pull fix if you wanted. I seem \nto recall that being your code originally; you just need to have fetch() \nidentify that an object is in a pack, copy/link/symlink the index and \npack instead of the object file, and add the pack to the list of \nregistered packs. I've mostly been failing to deal with reading an index \nfile that is in some directory that hasn't been registered as somewhere to \nread from (i.e. the source repository).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}