{"thread":{"id":"36303","subject":"Bug report: Git 1.8 on Ubuntu 13.10 refs not valid","startedAt":"2014-03-27T14:45:34Z","lastAt":"2014-03-31T18:57:54Z","messageCount":5,"participants":["Siggi","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"237905","messageId":"5334398E.8090402@gmail.com","threadId":"36303","inReplyTo":null,"subject":"Bug report: Git 1.8 on Ubuntu 13.10 refs not valid","fromName":"Siggi","fromEmail":"siggin@gmail.com","sentAt":"2014-03-27T14:45:34Z","receivedAt":"2014-03-27T14:45:34Z","isPatch":false,"sender":{"key":"siggin@gmail.com","avatar":null},"body":"Hi,\nI'm running:\n\nUbuntu 13.10 64 bit\n\nand git version\ngit:amd64/saucy 1:1.8.3.2-1 uptodate\n\nmy remote repository is on a Chiliprojekt server (a fork of Redmine).\n\ncloning the repo over http results in following error:\n\nsneher@sneher-XPS:~/Dokumente/test$ git clone \nhttp://sneher@git.projects.gwdg.de/xrd-csd.git\nKlone nach 'xrd-csd'...\nPassword for 'http://sneher@git.projects.gwdg.de':\nfatal: http://sneher@git.projects.gwdg.de/xrd-csd.git/info/refs not \nvalid: is this a git repository?\n\nthe content of ../info/refs looks like this\n\ne49ae34096fd6fff3d1e7b8e7b6e78ae29bad913\trefs/heads/0.2.2\n3d375b2f7eeeb7bc12b24cc8181aa085f471ba10\trefs/heads/master\nf7a69735c1e2cb8363be849afa9e9bfdf2db61c6\trefs/heads/new_lab\n879ccace941ea6dc83876b1dcfcc099e5c7e5b42\trefs/heads/testing\n2f9504da3febcdafb9cb92806e7e178144fec0c9\trefs/remotes/origin/HEAD\n2f9504da3febcdafb9cb92806e7e178144fec0c9\trefs/remotes/origin/master\nf7a69735c1e2cb8363be849afa9e9bfdf2db61c6\trefs/remotes/origin/new_lab\n58fe57f5a2a0c8e8096c62f8ab8be2077c592e53\trefs/remotes/origin/testing\n4b64a990dc1534abcccfb7f8c22f0cc5388e9db8\trefs/tags/0.1.0\na90ce817ca3bde41ce6c88cf22a9993bd7560f55\trefs/tags/0.1.1\n9a25635e866979b044b83f914cfd993a7031a9ca\trefs/tags/0.1.2\n5a94e698b1042b34a25c87ced98f5f42d40e2578\trefs/tags/0.2.0\n7cb00e325c1fb9a4112700744237f873bd5bae16\trefs/tags/0.2.1\n\n\n\nI use to have the same problem on a different Ubuntu version (12.10). There the problem occurede with the git 1.8 update. I just switcht back to the older version.\n\nProblem is, there is no older version for saucy.\n\nThanks for your help! and, in case this do to my inability, sorry for bugging you!\n\nSiggi\n"},{"id":"237927","messageId":"20140327184916.GA28668@sigill.intra.peff.net","threadId":"36303","inReplyTo":"5334398E.8090402@gmail.com","subject":"Re: Bug report: Git 1.8 on Ubuntu 13.10 refs not valid","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-27T18:49:16Z","receivedAt":"2014-03-27T18:49:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 27, 2014 at 03:45:34PM +0100, Siggi wrote:\n\n> and git version\n> git:amd64/saucy 1:1.8.3.2-1 uptodate\n> \n> my remote repository is on a Chiliprojekt server (a fork of Redmine).\n> \n> cloning the repo over http results in following error:\n> \n> sneher@sneher-XPS:~/Dokumente/test$ git clone\n> http://sneher@git.projects.gwdg.de/xrd-csd.git\n> Klone nach 'xrd-csd'...\n> Password for 'http://sneher@git.projects.gwdg.de':\n> fatal: http://sneher@git.projects.gwdg.de/xrd-csd.git/info/refs not valid:\n> is this a git repository?\n\nHmm.  The only way to trigger that message is if the dumb info/refs\noutput from the server is not valid. In particular, it is looking for\nthe tab character between the sha1 and the refs, and making sure that\nthe sha1 is exactly 40 characters.\n\nI noticed other people having the problem, too:\n\n  https://github.com/kubitron/redmine_git_hosting/issues/106\n\nso I think it is related to the output that the redmine plugin is\nproducing. But the interesting thing is that the plugin is supposed to\nenable git's smart-http protocol. But the error message you are seeing\nindicates that the client thinks it is doing a \"dumb\" http fetch.\n\nThe parsing code did not change in the v1.8.x series, but the logic to\ndetermine whether we are using smart/dumb http did change. For example,\nwe now actually check the content-type returned by the server (which\nshould be \"application/x-git-upload-pack-advertisement\").\n\nCan you try running your clone with GIT_CURL_VERBOSE=1 in the\nenvironment? That should show the headers (including content-type). Do\nbe careful when sharing the output; I believe it will contain\n\"Authorization\" lines that have your base64-encoded password on them.\n\nAlso, I would be curious to see the output of:\n\n  curl http://sneher@git.projects.gwdg.de/xrd-csd.git/info/refs | cat -A\n\nMy suspicion is that it is really smart-http output, but the client is\nparsing it as dumb-http output (and probably because of the content-type\nmentioned above).\n\n-Peff\n"},{"id":"238118","messageId":"20140331180118.GA31023@sigill.intra.peff.net","threadId":"36303","inReplyTo":"5339A38D.1080504@gmail.com","subject":"Re: Bug report: Git 1.8 on Ubuntu 13.10 refs not valid","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-31T18:01:18Z","receivedAt":"2014-03-31T18:01:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 31, 2014 at 07:19:09PM +0200, Siggi wrote:\n\n> here are the two outputs you wanted to see.\n\nThe interesting bit is at the end...\n\n> < HTTP/1.1 200 OK\n> < Date: Mon, 31 Mar 2014 17:04:57 GMT\n> * Server Apache/2.2.22 (Ubuntu) is not blacklisted\n> < Server: Apache/2.2.22 (Ubuntu)\n> < X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.19\n> < ETag: \"2ab570112563de50022189f0a2ffcdd4\"\n> < Pragma: no-cache\n> < Expires: Fri, 01 Jan 1980 00:00:00 GMT\n> < X-Runtime: 72\n> < Cache-Control: no-cache, max-age=0, must-revalidate\n> < Content-Length: 1047\n> < Status: 200\n> < Content-Type: application/x-git-upload-pack-advertisement; charset=utf-8\n\nThis content-type is the problem. There should not be a charset\nparameter (it is meaningless, and it throws off git's content-type\ncheck). So your web server configuration (or the redmine git plugin)\nshould be fixed, but you'll have to talk to redmine folks to figure that\npart out.\n\nThat being said, git _could_ be more liberal in accepting a content-type\nwith parameters (even though it does not know about any parameters, and\ncharset here is completely meaningless). I have mixed feelings on that.\n\n-Peff\n"},{"id":"238121","messageId":"xmqqbnwm6x5i.fsf@gitster.dls.corp.google.com","threadId":"36303","inReplyTo":"20140331180118.GA31023@sigill.intra.peff.net","subject":"Re: Bug report: Git 1.8 on Ubuntu 13.10 refs not valid","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-31T18:27:53Z","receivedAt":"2014-03-31T18:27:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> That being said, git _could_ be more liberal in accepting a content-type\n> with parameters (even though it does not know about any parameters, and\n> charset here is completely meaningless). I have mixed feelings on that.\n\nIt may be just a matter of replacing strbuf_cmp() with \"the initial\npart must be this string\" followed by \"it could have an optional\nwhitespaces and semicolon after that\", but I share the mixed\nfeelings.\n\nI am not sure if it is a right thing to follow \"be liberal to\naccept\" dictum in this case.  It may be liberal in accepting\nblindly, but if the other end is asking a behaviour that is not\nstandard (but perhaps in future versions of Git such an enhanced\nservice may be implemented by the client), by ignoring the parameter\nwe do not even know about how to handle, we would be giving surprises\nto the overall protocol exchange.\n"},{"id":"238126","messageId":"20140331185754.GA4426@sigill.intra.peff.net","threadId":"36303","inReplyTo":"xmqqbnwm6x5i.fsf@gitster.dls.corp.google.com","subject":"Re: Bug report: Git 1.8 on Ubuntu 13.10 refs not valid","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-31T18:57:54Z","receivedAt":"2014-03-31T18:57:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 31, 2014 at 11:27:53AM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > That being said, git _could_ be more liberal in accepting a content-type\n> > with parameters (even though it does not know about any parameters, and\n> > charset here is completely meaningless). I have mixed feelings on that.\n> \n> It may be just a matter of replacing strbuf_cmp() with \"the initial\n> part must be this string\" followed by \"it could have an optional\n> whitespaces and semicolon after that\", but I share the mixed\n> feelings.\n\nYeah, I think something like this is probably enough:\n\ndiff --git a/remote-curl.c b/remote-curl.c\nindex 52c2d96..be21fb6 100644\n--- a/remote-curl.c\n+++ b/remote-curl.c\n@@ -221,6 +221,13 @@ static int show_http_message(struct strbuf *type, struct strbuf *msg)\n \treturn 0;\n }\n \n+static int match_content_type(struct strbuf *have, struct strbuf *want)\n+{\n+\tif (!starts_with(have->buf, want->buf))\n+\t\treturn 0;\n+\treturn have->len == want->len || have->buf[want->len] == ';';\n+}\n+\n static struct discovery* discover_refs(const char *service, int for_push)\n {\n \tstruct strbuf exp = STRBUF_INIT;\n@@ -277,7 +284,7 @@ static struct discovery* discover_refs(const char *service, int for_push)\n \tstrbuf_addf(&exp, \"application/x-%s-advertisement\", service);\n \tif (maybe_smart &&\n \t    (5 <= last->len && last->buf[4] == '#') &&\n-\t    !strbuf_cmp(&exp, &type)) {\n+\t    match_content_type(type.buf, exp.buf)) {\n \t\tchar *line;\n \n \t\t/*\n\nthough perhaps there are exotic whitespace rules that we would also need\nto allow. Either way, I do not think it is the implementation that is\nthe problem, but rather the semantics.\n\n> I am not sure if it is a right thing to follow \"be liberal to\n> accept\" dictum in this case.  It may be liberal in accepting\n> blindly, but if the other end is asking a behaviour that is not\n> standard (but perhaps in future versions of Git such an enhanced\n> service may be implemented by the client), by ignoring the parameter\n> we do not even know about how to handle, we would be giving surprises\n> to the overall protocol exchange.\n\nI actually think ignoring them could provide room for future expansion\nin git (i.e., we could add new c-t parameters with the knowledge that\nexisting git would ignore them). So there is a potential upside.  But\ncurrent git does _not_ ignore them. Git v1.10 (or 2.0, or whatever)\ncould, but we would have to wait for old versions to die out before\nmaking that assumption anyway.\n\nIt's also possible that we would want to intentionally break\ncompatibility (to say \"if you do not understand foo=bar, then do not\neven process this\"). But I don't think that is a big deal, as we could\nalready switch the content-type itself (\"x-upload-pack-advertisement2\"\nor something). And if we really wanted to dump extra optional data into\nthe http conversation, we can already do so with http headers.\n\nSo really, I do not see us ever realistically expanding into\ncontent-type parameters. This would _just_ be about handling odd\nimplementations. And there I can see it as us being nice (I do not think\n\"charset\" is doing anything here), or us being careful about broken\nimplementations (why would one add a charset parameter at all? If the\nimplementation is blindly re-encoding to utf8 or something, it could\nvery well be corrupting the data in rare cases).\n\nGiven that there is only one implementation known to this in the first\nplace, I'd be inclined to say \"fix that implementation\". If it becomes\na widespread problem, then we can think about loosening the check after\nreviewing exactly what each implementation is doing.\n\nI think all of that is to say I'm violently agreeing with you. But\nhaving tried to think it through, I felt it was worth posting the more\ndetailed thought process.\n\n-Peff\n"}]}