{"thread":{"id":"4371","subject":"HTTP questions","startedAt":"2006-06-01T23:24:37Z","lastAt":"2006-06-03T07:58:37Z","messageCount":9,"participants":["Nick Hengeveld","Junio C Hamano","Linus Torvalds","Becky Bruce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21068","messageId":"20060601232437.GD12261@reactrix.com","threadId":"4371","inReplyTo":null,"subject":"HTTP questions","fromName":"Nick Hengeveld","fromEmail":"nickh@reactrix.com","sentAt":"2006-06-01T23:24:37Z","receivedAt":"2006-06-01T23:24:37Z","isPatch":false,"sender":{"key":"nickh@reactrix.com","avatar":null},"body":"While testing recent http-fetch changes with a current checkout of next,\nI noticed a couple of things:\n\n- \"git push\" seems to pass --thin by default to http-push, which\n subsequently barfs because that's not a valid http-push option.\n Should it be? Should it be silently ignored? Should git-push not\n default to --thin when pushing with HTTP transport?\n\n- when I clone, http-fetch outputs a whole bunch of \n \"error: Could not read ...\" messages - is that expected?\n\n-- \nFor a successful technology, reality must take precedence over public\nrelations, for nature cannot be fooled.\n"},{"id":"21090","messageId":"7vhd34dptq.fsf@assigned-by-dhcp.cox.net","threadId":"4371","inReplyTo":"20060601232437.GD12261@reactrix.com","subject":"Re: HTTP questions","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-02T06:38:57Z","receivedAt":"2006-06-02T06:38:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Hengeveld writes:\n\n> - \"git push\" seems to pass --thin by default to http-push, which\n> subsequently barfs because that's not a valid http-push option.\n> Should it be? Should it be silently ignored? Should git-push not\n> default to --thin when pushing with HTTP transport?\n\nThe way I understand http-push works is that it does not use\npacked transfer, so I presume even if we give --thin as a hint\nit cannot even take advantage of it. Probably we should stop\npassing --thin to http transport (git native one uses it as a\ncue that it can generate baseless deltas in the resulting pack).\n\n> - when I clone, http-fetch outputs a whole bunch of \n> \"error: Could not read ...\" messages - is that expected?\n\nThe clone over http seems to be severely broken in \"next\" right\nnow. The one in \"master\" seems to be OK. bisecting suggests\nthe breakage is coming from the tree parser rewrite.\n\nbisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.\n"},{"id":"21112","messageId":"7vac8vbgqg.fsf_-_@assigned-by-dhcp.cox.net","threadId":"4371","inReplyTo":"7vhd34dptq.fsf@assigned-by-dhcp.cox.net","subject":"http-fetch troubles","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-02T17:38:15Z","receivedAt":"2006-06-02T17:38:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Nick Hengeveld writes:\n>\n>> - \"git push\" seems to pass --thin by default to http-push, which\n>> subsequently barfs because that's not a valid http-push option.\n>> Should it be? Should it be silently ignored? Should git-push not\n>> default to --thin when pushing with HTTP transport?\n>\n> The way I understand http-push works is that it does not use\n> packed transfer, so I presume even if we give --thin as a hint\n> it cannot even take advantage of it. Probably we should stop\n> passing --thin to http transport (git native one uses it as a\n> cue that it can generate baseless deltas in the resulting pack).\n>\n>> - when I clone, http-fetch outputs a whole bunch of \n>> \"error: Could not read ...\" messages - is that expected?\n>\n> The clone over http seems to be severely broken in \"next\" right\n> now. The one in \"master\" seems to be OK. bisecting suggests\n> the breakage is coming from the tree parser rewrite.\n>\n> bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.\n\nI've pushed out Nick's http-fetch fixes in \"master\" to see if it\nfixes problems for people. Right now the one in \"next\" branch\nseems to be having unrelated problems coming from another topic\nwhich I haven't started tracking down yet.\n"},{"id":"21119","messageId":"7vmzcv9pba.fsf@assigned-by-dhcp.cox.net","threadId":"4371","inReplyTo":"7vac8vbgqg.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: http-fetch troubles","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-02T22:15:53Z","receivedAt":"2006-06-02T22:15:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I think this fixes the http trouble with tree parser change in\nthe \"next\" branch.\n\n-- >8 --\nfetch.c: do not call process_tree() from process_tree().\n\nThis function reads a freshly fetched tree object, and schedules\nthe objects pointed by it for further fetching, so calling lookup-tree\nand doing process_tree() recursively from there does not make\nmuch sense. We need to use process() on it to make sure we\nfetch it first.\n\nSigned-off-by: Junio C Hamano \n---\ndiff --git a/fetch.c b/fetch.c\nindex ec2d8c3..107504b 100644\n--- a/fetch.c\n+++ b/fetch.c\n@@ -46,13 +46,20 @@ static int process_tree(struct tree *tre\n \tdesc.buf = tree->buffer;\n \tdesc.size = tree->size;\n \twhile (tree_entry(&desc, &entry)) {\n+\t\tstruct object *obj = NULL;\n+\n \t\tif (S_ISDIR(entry.mode)) {\n \t\t\tstruct tree *tree = lookup_tree(entry.sha1);\n-\t\t\tprocess_tree(tree);\n-\t\t} else {\n+\t\t\tif (tree)\n+\t\t\t\tobj = &tree->object;\n+\t\t}\n+\t\telse {\n \t\t\tstruct blob *blob = lookup_blob(entry.sha1);\n-\t\t\tprocess(&blob->object);\n+\t\t\tif (blob)\n+\t\t\t\tobj = &blob->object;\n \t\t}\n+\t\tif (!obj || process(obj))\n+\t\t\treturn -1;\n \t}\n \tfree(tree->buffer);\n \ttree->buffer = NULL;\n"},{"id":"21120","messageId":"Pine.LNX.4.64.0606021527340.5498@g5.osdl.org","threadId":"4371","inReplyTo":"7vmzcv9pba.fsf@assigned-by-dhcp.cox.net","subject":"Re: http-fetch troubles","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-02T22:34:34Z","receivedAt":"2006-06-02T22:34:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 2 Jun 2006, Junio C Hamano wrote:\n>\n> I think this fixes the http trouble with tree parser change in\n> the \"next\" branch.\n\nAhh, my bad. That happened as a bug in my original understanding of that \nfetch.c thing.\n\nYour fix looks obviously fine,\n\n Linus\n"},{"id":"21122","messageId":"1C422237-D48C-4A30-9BDD-5C165222873D@freescale.com","threadId":"4371","inReplyTo":"7vac8vbgqg.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: http-fetch troubles","fromName":"Becky Bruce","fromEmail":"becky.bruce@freescale.com","sentAt":"2006-06-03T01:13:12Z","receivedAt":"2006-06-03T01:13:12Z","isPatch":false,"sender":{"key":"becky.bruce@freescale.com","avatar":null},"body":"\nWoohoo! The stuff you moved to master (which is what I was building \nfrom, not \"next\", as Nick pointed out) has fixed the git-http-fetch \nsegfault problem I was seeing.\n\nThanks!\n-Becky\n\nOn Jun 2, 2006, at 12:38 PM, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n>\n>> Nick Hengeveld writes:\n>>\n>>> - \"git push\" seems to pass --thin by default to http-push, which\n>>> subsequently barfs because that's not a valid http-push option.\n>>> Should it be? Should it be silently ignored? Should git-push not\n>>> default to --thin when pushing with HTTP transport?\n>>\n>> The way I understand http-push works is that it does not use\n>> packed transfer, so I presume even if we give --thin as a hint\n>> it cannot even take advantage of it. Probably we should stop\n>> passing --thin to http transport (git native one uses it as a\n>> cue that it can generate baseless deltas in the resulting pack).\n>>\n>>> - when I clone, http-fetch outputs a whole bunch of\n>>> \"error: Could not read ...\" messages - is that expected?\n>>\n>> The clone over http seems to be severely broken in \"next\" right\n>> now. The one in \"master\" seems to be OK. bisecting suggests\n>> the breakage is coming from the tree parser rewrite.\n>>\n>> bisect points at 136f2e548a34f1f504b0f062f87ddf33e8d6e83b.\n>\n> I've pushed out Nick's http-fetch fixes in \"master\" to see if it\n> fixes problems for people. Right now the one in \"next\" branch\n> seems to be having unrelated problems coming from another topic\n> which I haven't started tracking down yet.\n>\n>\n"},{"id":"21123","messageId":"7virnj9gkf.fsf@assigned-by-dhcp.cox.net","threadId":"4371","inReplyTo":"1C422237-D48C-4A30-9BDD-5C165222873D@freescale.com","subject":"Re: http-fetch troubles","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-03T01:24:48Z","receivedAt":"2006-06-03T01:24:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Becky Bruce writes:\n\n> Woohoo! The stuff you moved to master (which is what I was building\n> from, not \"next\", as Nick pointed out) has fixed the git-http-fetch\n> segfault problem I was seeing.\n>\n> Thanks!\n\nThanks Nick for fixing, and Becky for confirming.\n\n... and I take all the credit ;-).\n\nI haven't pushed it out yet, but I believe \"next\" is also good\nto go.\n"},{"id":"21124","messageId":"Pine.LNX.4.64.0606021925350.5498@g5.osdl.org","threadId":"4371","inReplyTo":"7virnj9gkf.fsf@assigned-by-dhcp.cox.net","subject":"Re: http-fetch troubles","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-03T02:26:04Z","receivedAt":"2006-06-03T02:26:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 2 Jun 2006, Junio C Hamano wrote:\n> \n> ... and I take all the credit ;-).\n\nI always knew you'd work out as a maintainer.\n\n\t\tLinus\n"},{"id":"21128","messageId":"7vejy6acwi.fsf@assigned-by-dhcp.cox.net","threadId":"4371","inReplyTo":"Pine.LNX.4.64.0606021925350.5498@g5.osdl.org","subject":"Re: http-fetch troubles","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-03T07:58:37Z","receivedAt":"2006-06-03T07:58:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 2 Jun 2006, Junio C Hamano wrote:\n>> \n>> ... and I take all the credit ;-).\n>\n> I always knew you'd work out as a maintainer.\n>\n> \t\tLinus\n\nThanks for the compliment. I realize that is your way to take\nthe credit ;-).\n"}]}