{"thread":{"id":"28029","subject":"[RFC] helping smart-http/stateless-rpc fetch race","startedAt":"2011-08-05T20:54:06Z","lastAt":"2011-08-08T23:42:27Z","messageCount":10,"participants":["Junio C Hamano","Shawn Pearce","Sverre Rabbelier","Ilari Liusvaara"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"172994","messageId":"7vbow337gx.fsf@alter.siamese.dyndns.org","threadId":"28029","inReplyTo":null,"subject":"[RFC] helping smart-http/stateless-rpc fetch race","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-05T20:54:06Z","receivedAt":"2011-08-05T20:54:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A request to fetch from a client over smart HTTP protocol is served in\nmultiple steps. In the first round, the server side shows the set of refs\nit has and their values, and the client picks from them and sends \"I want\nto fetch the history leading to these commits\".\n\nWhen the server tries to respond to this second request, its refs may have\nprogressed by a push from elsewhere. By design, we do not allow fetching\nobjects that are not at the tip of an advertised ref, and the server\nrejects such a request. The client needs to try again, which is not ideal\nespecially for a busy server.\n\nTeach --allow-non-tip option to upload-pack (which is the workhorse driven\nby git-daemon and smart http server interface) that lets it server commits\nthat are not at the tip of any advertised ref, as long as they are\nreachable from advertised refs.\n\nSigned-off-by: Junio C Hamano \n---\n\n * I'll leave it to interested parties who are more qualified than I am to\n update remote-curl nor http-backend to actually ask upload-pack to use\n this new logic ;-)\n\n upload-pack.c | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----\n 1 files changed, 95 insertions(+), 9 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex ce5cbbe..76be9ff 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -10,6 +10,7 @@\n #include \"revision.h\"\n #include \"list-objects.h\"\n #include \"run-command.h\"\n+#include \"sigchain.h\"\n \n static const char upload_pack_usage[] = \"git upload-pack [--strict] [--timeout=] \";\n \n@@ -42,6 +43,7 @@ static int use_sideband;\n static int debug_fd;\n static int advertise_refs;\n static int stateless_rpc;\n+static int allow_non_tip;\n \n static void reset_timeout(void)\n {\n@@ -498,11 +500,87 @@ static int get_common_commits(void)\n \t}\n }\n \n+static void check_non_tip(void)\n+{\n+\tstatic const char *argv[] = {\n+\t\t\"rev-list\", \"--stdin\", NULL,\n+\t};\n+\tstatic struct child_process cmd;\n+\tint i;\n+\tchar namebuf[42]; /* ^ + SHA-1 + LF */\n+\n+\tif (!allow_non_tip)\n+\t\tgoto error;\n+\n+\tcmd.argv = argv;\n+\tcmd.git_cmd = 1;\n+\tcmd.no_stderr = 1;\n+\tcmd.in = -1;\n+\tcmd.out = -1;\n+\n+\tif (start_command(&cmd))\n+\t\tgoto error;\n+\n+\t/*\n+\t * If rev-list --stdin encounters an unknown commit, it\n+\t * terminates, which will cause SIGPIPE in the write loop\n+\t * below.\n+\t */\n+\tsigchain_push(SIGPIPE, SIG_IGN);\n+\n+\tnamebuf[0] = '^';\n+\tnamebuf[41] = '\\n';\n+\tfor (i = get_max_object_index(); 0 < i; ) {\n+\t\tstruct object *o = get_indexed_object(--i);\n+\t\tif (!(o->flags & OUR_REF))\n+\t\t\tcontinue;\n+\t\tmemcpy(namebuf + 1, sha1_to_hex(o->sha1), 40);\n+\t\tif (write_in_full(cmd.in, namebuf, 42) < 0)\n+\t\t\tgoto error;\n+\t}\n+\tnamebuf[40] = '\\n';\n+\tfor (i = 0; i < want_obj.nr; i++) {\n+\t\tstruct object *o = want_obj.objects[i].item;\n+\t\tif (o->flags & OUR_REF)\n+\t\t\tcontinue;\n+\t\tmemcpy(namebuf, sha1_to_hex(o->sha1), 40);\n+\t\tif (write_in_full(cmd.in, namebuf, 41) < 0)\n+\t\t\tgoto error;\n+\t}\n+\tclose(cmd.in);\n+\n+\tsigchain_pop(SIGPIPE);\n+\n+\t/*\n+\t * The commits out of the rev-list are not ancestors of\n+\t * our ref.\n+\t */\n+\ti = read_in_full(cmd.out, namebuf, 1);\n+\tif (i)\n+\t\tgoto error;\n+\tclose(cmd.out);\n+\n+\t/*\n+\t * rev-list may have died by encountering a bad commit\n+\t * in the history, in which case we do want to bail out\n+\t * even when it showed no commit.\n+\t */\n+\tif (finish_command(&cmd))\n+\t\tgoto error;\n+\n+\t/* All the non-tip ones are ancestors of what we advertised */\n+\treturn;\n+\n+error:\n+\tdie(\"git upload-pack: not our ref\");\n+}\n+\n static void receive_needs(void)\n {\n \tstruct object_array shallows = OBJECT_ARRAY_INIT;\n \tstatic char line[1000];\n \tint len, depth = 0;\n+\tint has_non_tip = 0;\n \n \tshallow_nr = 0;\n \tif (debug_fd)\n@@ -559,26 +637,30 @@ static void receive_needs(void)\n \t\tif (strstr(line+45, \"include-tag\"))\n \t\t\tuse_include_tag = 1;\n \n-\t\t/* We have sent all our refs already, and the other end\n-\t\t * should have chosen out of them; otherwise they are\n-\t\t * asking for nonsense.\n-\t\t *\n-\t\t * Hmph. We may later want to allow \"want\" line that\n-\t\t * asks for something like \"master~10\" (symbolic)...\n-\t\t * would it make sense? I don't know.\n-\t\t */\n \t\to = lookup_object(sha1_buf);\n-\t\tif (!o || !(o->flags & OUR_REF))\n+\t\tif (!o)\n \t\t\tdie(\"git upload-pack: not our ref %s\",\n \t\t\t sha1_to_hex(sha1_buf));\n \t\tif (!(o->flags & WANTED)) {\n \t\t\to->flags |= WANTED;\n+\t\t\tif (!(o->flags & OUR_REF))\n+\t\t\t\thas_non_tip = 1;\n \t\t\tadd_object_array(o, NULL, &want_obj);\n \t\t}\n \t}\n \tif (debug_fd)\n \t\twrite_str_in_full(debug_fd, \"#E\\n\");\n \n+\t/*\n+\t * We have sent all our refs already, and the other end\n+\t * should have chosen out of them. When we are operating\n+\t * in the stateless RPC mode, however, their choice may\n+\t * have been based on the set of older refs advertised\n+\t * by another process that handled the initial request.\n+\t */\n+\tif (has_non_tip)\n+\t\tcheck_non_tip();\n+\n \tif (!use_sideband && daemon_mode)\n \t\tno_progress = 1;\n \n@@ -720,6 +802,10 @@ int main(int argc, char **argv)\n \t\t\tstateless_rpc = 1;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strcmp(arg, \"--allow-non-tip\")) {\n+\t\t\tallow_non_tip = 1;\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!strcmp(arg, \"--strict\")) {\n \t\t\tstrict = 1;\n \t\t\tcontinue;\n"},{"id":"173070","messageId":"CAJo=hJvdMCyU-5wzy0p1r+QJxXU=DJTE+Mu5G6pk9iAwAD51mA@mail.gmail.com","threadId":"28029","inReplyTo":"7vbow337gx.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-08-06T21:05:31Z","receivedAt":"2011-08-06T21:05:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Fri, Aug 5, 2011 at 13:54, Junio C Hamano wrote:\n> A request to fetch from a client over smart HTTP protocol is served in\n> multiple steps. In the first round, the server side shows the set of refs\n> it has and their values, and the client picks from them and sends \"I want\n> to fetch the history leading to these commits\".\n>\n> When the server tries to respond to this second request, its refs may have\n> progressed by a push from elsewhere. By design, we do not allow fetching\n> objects that are not at the tip of an advertised ref, and the server\n> rejects such a request. The client needs to try again, which is not ideal\n> especially for a busy server.\n>\n> Teach --allow-non-tip option to upload-pack (which is the workhorse driven\n> by git-daemon and smart http server interface) that lets it server commits\n> that are not at the tip of any advertised ref, as long as they are\n> reachable from advertised refs.\n>\n> Signed-off-by: Junio C Hamano \n> ---\n>\n>  * I'll leave it to interested parties who are more qualified than I am to\n>   update remote-curl nor http-backend to actually ask upload-pack to use\n>   this new logic ;-)\n\nWhy a new --allow-non-tip flag? Why not always do this with the\nexisting --stateless-rpc flag? I think the only time it is reasonable\nto allow a non-tip want line is during the smart HTTP usage where the\nrequest has spanned processes and the references may have moved in the\ninterm. Over a git:// or SSH where its the same server process and the\nrefs were cached at startup (and thus cannot move), it isn't\nreasonable to allow a non-tip want.\n\nOtherwise the patch looks good to me. This should fix some issues with\nvery busy repositories being fetched over smart HTTP.\n\n-- \nShawn.\n"},{"id":"173117","messageId":"7vbow01ols.fsf@alter.siamese.dyndns.org","threadId":"28029","inReplyTo":"CAJo=hJvdMCyU-5wzy0p1r+QJxXU=DJTE+Mu5G6pk9iAwAD51mA@mail.gmail.com","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-08T05:03:43Z","receivedAt":"2011-08-08T05:03:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Why a new --allow-non-tip flag? Why not always do this with the\n> existing --stateless-rpc flag?\n\nIt certainly would be much easier from implementation point of view, but I\ndid it that way for two and half reasons:\n\n (1) It might make sense to give admins who run upload-pack not behind\n smart-http an option to allow fetching from a non-tip; and\n\n (2) It also might make sense to let admins who do run upload-pack behind\n smart-http force re-fetching when the race is encountered.\n\nand the remaining half-reason was that I was too lazy to think things\nthrough to refute the above two \"might make sense\" and convince myself\nthat they should instead be \"is not necessary\".\n"},{"id":"173139","messageId":"7vsjpbzv07.fsf@alter.siamese.dyndns.org","threadId":"28029","inReplyTo":"7vbow01ols.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-08T17:13:44Z","receivedAt":"2011-08-08T17:13:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Shawn Pearce writes:\n>\n>> Why a new --allow-non-tip flag? Why not always do this with the\n>> existing --stateless-rpc flag?\n>\n> It certainly would be much easier from implementation point of view, but I\n> did it that way for two and half reasons:\n>\n> (1) It might make sense to give admins who run upload-pack not behind\n> smart-http an option to allow fetching from a non-tip; and\n>\n> (2) It also might make sense to let admins who do run upload-pack behind\n> smart-http force re-fetching when the race is encountered.\n>\n> and the remaining half-reason was that I was too lazy to think things\n> through to refute the above two \"might make sense\" and convince myself\n> that they should instead be \"is not necessary\".\n\nI still haven't convinced myself but here is a simplified one without the\nnew option (hence no need to touch the smart-http infrastructure).\n\n-- >8 --\nSubject: [PATCH] helping smart-http/stateless-rpc fetch race\n\nA request to fetch from a client over smart HTTP protocol is served in\nmultiple steps. In the first round, the server side shows the set of refs\nit has and their values, and the client picks from them and sends \"I want\nto fetch the history leading to these commits\".\n\nWhen the server tries to respond to this second request, its refs may have\nprogressed by a push from elsewhere. By design, we do not allow fetching\nobjects that are not at the tip of an advertised ref, and the server\nrejects such a request. The client needs to try again, which is not ideal\nespecially for a busy server.\n\nTeach upload-pack (which is the workhorse driven by git-daemon and smart\nhttp server interface) that it is OK for a smart-http client to ask for\ncommits that are not at the tip of any advertised ref, as long as they are\nreachable from advertised refs.\n\nSigned-off-by: Junio C Hamano \n---\n upload-pack.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----\n 1 files changed, 99 insertions(+), 9 deletions(-)\n\ndiff --git a/upload-pack.c b/upload-pack.c\nindex ce5cbbe..30cf941 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -10,6 +10,7 @@\n #include \"revision.h\"\n #include \"list-objects.h\"\n #include \"run-command.h\"\n+#include \"sigchain.h\"\n \n static const char upload_pack_usage[] = \"git upload-pack [--strict] [--timeout=] \";\n \n@@ -498,11 +499,96 @@ static int get_common_commits(void)\n \t}\n }\n \n+static void check_non_tip(void)\n+{\n+\tstatic const char *argv[] = {\n+\t\t\"rev-list\", \"--stdin\", NULL,\n+\t};\n+\tstatic struct child_process cmd;\n+\tstruct object *o;\n+\tchar namebuf[42]; /* ^ + SHA-1 + LF */\n+\tint i;\n+\n+\t/* In the normal in-process case non-tip request can never happen */\n+\tif (!stateless_rpc)\n+\t\tgoto error;\n+\n+\tcmd.argv = argv;\n+\tcmd.git_cmd = 1;\n+\tcmd.no_stderr = 1;\n+\tcmd.in = -1;\n+\tcmd.out = -1;\n+\n+\tif (start_command(&cmd))\n+\t\tgoto error;\n+\n+\t/*\n+\t * If rev-list --stdin encounters an unknown commit, it\n+\t * terminates, which will cause SIGPIPE in the write loop\n+\t * below.\n+\t */\n+\tsigchain_push(SIGPIPE, SIG_IGN);\n+\n+\tnamebuf[0] = '^';\n+\tnamebuf[41] = '\\n';\n+\tfor (i = get_max_object_index(); 0 < i; ) {\n+\t\to = get_indexed_object(--i);\n+\t\tif (!(o->flags & OUR_REF))\n+\t\t\tcontinue;\n+\t\tmemcpy(namebuf + 1, sha1_to_hex(o->sha1), 40);\n+\t\tif (write_in_full(cmd.in, namebuf, 42) < 0)\n+\t\t\tgoto error;\n+\t}\n+\tnamebuf[40] = '\\n';\n+\tfor (i = 0; i < want_obj.nr; i++) {\n+\t\to = want_obj.objects[i].item;\n+\t\tif (o->flags & OUR_REF)\n+\t\t\tcontinue;\n+\t\tmemcpy(namebuf, sha1_to_hex(o->sha1), 40);\n+\t\tif (write_in_full(cmd.in, namebuf, 41) < 0)\n+\t\t\tgoto error;\n+\t}\n+\tclose(cmd.in);\n+\n+\tsigchain_pop(SIGPIPE);\n+\n+\t/*\n+\t * The commits out of the rev-list are not ancestors of\n+\t * our ref.\n+\t */\n+\ti = read_in_full(cmd.out, namebuf, 1);\n+\tif (i)\n+\t\tgoto error;\n+\tclose(cmd.out);\n+\n+\t/*\n+\t * rev-list may have died by encountering a bad commit\n+\t * in the history, in which case we do want to bail out\n+\t * even when it showed no commit.\n+\t */\n+\tif (finish_command(&cmd))\n+\t\tgoto error;\n+\n+\t/* All the non-tip ones are ancestors of what we advertised */\n+\treturn;\n+\n+error:\n+\t/* Pick one of them (we know there at least is one) */\n+\tfor (i = 0; i < want_obj.nr; i++) {\n+\t\to = want_obj.objects[i].item;\n+\t\tif (!(o->flags & OUR_REF))\n+\t\t\tbreak;\n+\t}\n+\tdie(\"git upload-pack: not our ref %s\",\n+\t sha1_to_hex(o->sha1));\n+}\n+\n static void receive_needs(void)\n {\n \tstruct object_array shallows = OBJECT_ARRAY_INIT;\n \tstatic char line[1000];\n \tint len, depth = 0;\n+\tint has_non_tip = 0;\n \n \tshallow_nr = 0;\n \tif (debug_fd)\n@@ -559,26 +645,30 @@ static void receive_needs(void)\n \t\tif (strstr(line+45, \"include-tag\"))\n \t\t\tuse_include_tag = 1;\n \n-\t\t/* We have sent all our refs already, and the other end\n-\t\t * should have chosen out of them; otherwise they are\n-\t\t * asking for nonsense.\n-\t\t *\n-\t\t * Hmph. We may later want to allow \"want\" line that\n-\t\t * asks for something like \"master~10\" (symbolic)...\n-\t\t * would it make sense? I don't know.\n-\t\t */\n \t\to = lookup_object(sha1_buf);\n-\t\tif (!o || !(o->flags & OUR_REF))\n+\t\tif (!o)\n \t\t\tdie(\"git upload-pack: not our ref %s\",\n \t\t\t sha1_to_hex(sha1_buf));\n \t\tif (!(o->flags & WANTED)) {\n \t\t\to->flags |= WANTED;\n+\t\t\tif (!(o->flags & OUR_REF))\n+\t\t\t\thas_non_tip = 1;\n \t\t\tadd_object_array(o, NULL, &want_obj);\n \t\t}\n \t}\n \tif (debug_fd)\n \t\twrite_str_in_full(debug_fd, \"#E\\n\");\n \n+\t/*\n+\t * We have sent all our refs already, and the other end\n+\t * should have chosen out of them. When we are operating\n+\t * in the stateless RPC mode, however, their choice may\n+\t * have been based on the set of older refs advertised\n+\t * by another process that handled the initial request.\n+\t */\n+\tif (has_non_tip)\n+\t\tcheck_non_tip();\n+\n \tif (!use_sideband && daemon_mode)\n \t\tno_progress = 1;\n \n-- \n1.7.6.409.ge7a85\n"},{"id":"173160","messageId":"CAGdFq_i=8p4jvKo1C=UFpmQyPtUd9JOtr9VW8vn7viC0dQkQmg@mail.gmail.com","threadId":"28029","inReplyTo":"7vsjpbzv07.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2011-08-08T21:05:27Z","receivedAt":"2011-08-08T21:05:27Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Aug 8, 2011 at 19:13, Junio C Hamano wrote:\n>>  (1) It might make sense to give admins who run upload-pack not behind\n>>      smart-http an option to allow fetching from a non-tip; and\n\nYou said earlier it isn't needed since the server process caches the\nrefs for git and ssh, that leaves dumb-http right? If that is indeed\nthe case I think we can just argue that since smart-http is our\nsolution to the http problems, if admins want to make life easier for\nhttp fetches on busy repositories they should be using smart-http.\n\n>>  (2) It also might make sense to let admins who do run upload-pack behind\n>>      smart-http force re-fetching when the race is encountered.\n\nThis would mean that if you're running smart-http without this option\nenabled (because, say, you don't know it exists), your users have to\nre-fetch (a lot). The only upside would be that if the server _knows_\nwhat the user is asking for is outdated, that the user will know this\nright away. That doesn't fly though, since we allow exactly that for\ngit and ssh transfer.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"173181","messageId":"20110808230812.GA16974@LK-Perkele-VI.localdomain","threadId":"28029","inReplyTo":"CAGdFq_i=8p4jvKo1C=UFpmQyPtUd9JOtr9VW8vn7viC0dQkQmg@mail.gmail.com","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2011-08-08T23:08:12Z","receivedAt":"2011-08-08T23:08:12Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Mon, Aug 08, 2011 at 11:05:27PM +0200, Sverre Rabbelier wrote:\n> Heya,\n> \n> On Mon, Aug 8, 2011 at 19:13, Junio C Hamano wrote:\n> >>  (1) It might make sense to give admins who run upload-pack not behind\n> >>      smart-http an option to allow fetching from a non-tip; and\n> \n> You said earlier it isn't needed since the server process caches the\n> refs for git and ssh, that leaves dumb-http right?\n\nIt seems that everything currently possible falls into three\ncategories:\n\n1) Stateful upload-pack (git://, file://, ssh://, CONNECT): No fix\nneeded.\n2) Stateless upload-pack (smart http://, some bizarre helper):\nNeeds fix to avoid races.\n3) Dumb protocols (dumb http://, ftp://, rsync://): Won't invoke\nupload-pack anyway, no fix needed.\n\nSo I think that the only thing that needs the option to allow\nfetching from non-tips is anything using --stateless-rpc.\n\n-Ilari\n"},{"id":"173183","messageId":"7vty9rtrk4.fsf@alter.siamese.dyndns.org","threadId":"28029","inReplyTo":"20110808230812.GA16974@LK-Perkele-VI.localdomain","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-08T23:24:43Z","receivedAt":"2011-08-08T23:24:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ilari Liusvaara writes:\n\n> On Mon, Aug 08, 2011 at 11:05:27PM +0200, Sverre Rabbelier wrote:\n>> Heya,\n>> \n>> On Mon, Aug 8, 2011 at 19:13, Junio C Hamano wrote:\n>> >> (1) It might make sense to give admins who run upload-pack not behind\n>> >> smart-http an option to allow fetching from a non-tip; and\n>> \n>> You said earlier it isn't needed since the server process caches the\n>> refs for git and ssh, that leaves dumb-http right?\n>\n> It seems that everything currently possible falls into three\n> categories:\n>\n> 1) Stateful upload-pack (git://, file://, ssh://, CONNECT): No fix\n> needed.\n> 2) Stateless upload-pack (smart http://, some bizarre helper):\n> Needs fix to avoid races.\n> 3) Dumb protocols (dumb http://, ftp://, rsync://): Won't invoke\n> upload-pack anyway, no fix needed.\n>\n> So I think that the only thing that needs the option to allow\n> fetching from non-tips is anything using --stateless-rpc.\n\nThese (1) and (2) were never meant to be fixes to work around the\nsmart-http protocol limitation; I know \"No fix _needed_\" and it was never\na consideration to decide (or choose not to decide) about these two\npoints.\n\nA separate option would allow admins to let their clients ask to fetch\n4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref\nif they choose to. That is what (1) is about, and people who do not want\na separate option needs to argue that it is an unnecessary \"feature\".\n"},{"id":"173185","messageId":"7vpqkftrhg.fsf@alter.siamese.dyndns.org","threadId":"28029","inReplyTo":"7vty9rtrk4.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-08T23:26:19Z","receivedAt":"2011-08-08T23:26:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> A separate option would allow admins to let their clients ask to fetch\n> 4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref\n> if they choose to. That is what (1) is about, and people who do not want\n> a separate option needs to argue that it is an unnecessary \"feature\".\n\nBy the way, I personally do not think it is necessary, but as long timers\non the list may recall, this has come up on the list for a few times.\n"},{"id":"173186","messageId":"CAJo=hJu=nuy8Ws8PP16F=ay-Wp9vAdW_U113WLVCFs4hPQOeQA@mail.gmail.com","threadId":"28029","inReplyTo":"7vpqkftrhg.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-08-08T23:33:13Z","receivedAt":"2011-08-08T23:33:13Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Mon, Aug 8, 2011 at 16:26, Junio C Hamano wrote:\n> Junio C Hamano writes:\n>\n>> A separate option would allow admins to let their clients ask to fetch\n>> 4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref\n>> if they choose to. That is what (1) is about, and people who do not want\n>> a separate option needs to argue that it is an unnecessary \"feature\".\n>\n> By the way, I personally do not think it is necessary, but as long timers\n> on the list may recall, this has come up on the list for a few times.\n\nMy feeling is clients aren't likely to do this, or grow this feature\nanytime soon, so why add a backend option for it now? Lets add the\nfeature when the feature is necessary... and right now just fix the\nrace in smart HTTP.\n\n-- \nShawn.\n"},{"id":"173188","messageId":"7vei0vtqqk.fsf@alter.siamese.dyndns.org","threadId":"28029","inReplyTo":"CAJo=hJu=nuy8Ws8PP16F=ay-Wp9vAdW_U113WLVCFs4hPQOeQA@mail.gmail.com","subject":"Re: [RFC] helping smart-http/stateless-rpc fetch race","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-08-08T23:42:27Z","receivedAt":"2011-08-08T23:42:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> On Mon, Aug 8, 2011 at 16:26, Junio C Hamano wrote:\n>> Junio C Hamano writes:\n>>\n>>> A separate option would allow admins to let their clients ask to fetch\n>>> 4bc5fbf (that is v0.99~2) even if that commit is not at the tip of any ref\n>>> if they choose to. That is what (1) is about, and people who do not want\n>>> a separate option needs to argue that it is an unnecessary \"feature\".\n>>\n>> By the way, I personally do not think it is necessary, but as long timers\n>> on the list may recall, this has come up on the list for a few times.\n>\n> My feeling is clients aren't likely to do this, or grow this feature\n> anytime soon, so why add a backend option for it now? Lets add the\n> feature when the feature is necessary... and right now just fix the\n> race in smart HTTP.\n\nYes, that is what is queued in today's 'pu'.\n"}]}