On Thu, Mar 27, 2014 at 03:45:34PM +0100, Siggi wrote: > and git version > git:amd64/saucy 1:1.8.3.2-1 uptodate > > my remote repository is on a Chiliprojekt server (a fork of Redmine). > > cloning the repo over http results in following error: > > sneher@sneher-XPS:~/Dokumente/test$ git clone > http://sneher@xxxxxxxxxxxxxxxxxxxx/xrd-csd.git > Klone nach 'xrd-csd'... > Password for 'http://sneher@xxxxxxxxxxxxxxxxxxxx': > fatal: http://sneher@xxxxxxxxxxxxxxxxxxxx/xrd-csd.git/info/refs not valid: > is this a git repository? Hmm. The only way to trigger that message is if the dumb info/refs output from the server is not valid. In particular, it is looking for the tab character between the sha1 and the refs, and making sure that the sha1 is exactly 40 characters. I noticed other people having the problem, too: https://github.com/kubitron/redmine_git_hosting/issues/106 so I think it is related to the output that the redmine plugin is producing. But the interesting thing is that the plugin is supposed to enable git's smart-http protocol. But the error message you are seeing indicates that the client thinks it is doing a "dumb" http fetch. The parsing code did not change in the v1.8.x series, but the logic to determine whether we are using smart/dumb http did change. For example, we now actually check the content-type returned by the server (which should be "application/x-git-upload-pack-advertisement"). Can you try running your clone with GIT_CURL_VERBOSE=1 in the environment? That should show the headers (including content-type). Do be careful when sharing the output; I believe it will contain "Authorization" lines that have your base64-encoded password on them. Also, I would be curious to see the output of: curl http://sneher@xxxxxxxxxxxxxxxxxxxx/xrd-csd.git/info/refs | cat -A My suspicion is that it is really smart-http output, but the client is parsing it as dumb-http output (and probably because of the content-type mentioned above). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html