On Thu, Mar 27, 2014 at 03:45:34PM +0100, Siggi wrote:
> and git version
> git:amd64/saucy 1:126.96.36.199-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
> Klone nach 'xrd-csd'...
> Password for 'http://sne...@git.projects.gwdg.de':
> fatal: http://sne...@git.projects.gwdg.de/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:
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://sne...@git.projects.gwdg.de/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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html