Home/ Questions/Q 361483
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T12:53:36+00:00

I have installed msysGit on several of my computers and only have problems on

  • 0

I have installed msysGit on several of my computers and only have problems on one particular computer (my main work computer of course). ‘git clone’ does not work. When I run the clone command on a repository, this occurs:

C:\Projects>git clone git://github.com/[user]/[project].git
Initialized empty Git repository in C:/Projects/[project]/.git/

It starts populating the .git directory, but never pulls down anything else. I’ve left it going for a couple of hours to see if it would at least throw an error. It continues to sit there. If I try and cancel it, it works just fine. It just never seems to pull the repository down. I’ve tried this on multiple repositories from multiple places. Does anyone have a clue what may be happening?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Did you try to clone with the http address?

    The is currently a ticket with msysgit (issue 136) with the same problem, for which the current workaround is to clone with the http rather than the git address.

    Other moves to try:

    • GIT_TRACE=1 (and post the output)
    • try with other or older versions of msysgit
    • check for any firewall/antivirus issue on your main computer

    Here switching to an older version of msysgit could be the right option:
    See this GitHub support thread:

    Are you using the 1.6.4 prerelease of msysGit? There are known bugs with it.
    We recommend a stable version, such as 1.6.0.

    thanks chris, that’s it: after switching back to the previous version of msysGit (Git-1.6.3.2-preview20090608.exe) the problem does not occur any more.

    The problem might actually affect any Git1.6.4 and older:

    git tries to check if the pack file exists by sending out a HEAD request, but chokes on the 500 error that some (if not all) github returns.

    Using the repository used by the reporter:

    $ curl http://github.com/grails/grails.git/objects/info/packs
P pack-1290e84bed53bda28f0989dca48d836bd9104031.pack
P pack-bf40d38ae780512994e5127e832ed9d8853c186d.pack
P pack-f490d5f7d4671368f4a52c618ca9dce13b714ba1.pack
P pack-79e3a7f30e8989acc8403ac688be669a05384eef.pack

$ curl -I http://github.com/grails/grails.git/objects/pack/pack-bf40d38ae780512994e5127e832ed9d8853c186d.pack
HTTP/1.1 500 Internal Server Error
Server: nginx/0.6.26
Date: Fri, 04 Sep 2009 13:50:20 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Content-Length: 3193
Cache-Control: no-cache

    See this thread.
    The GitHub support teams is currently investigating the problem:

    I don’t think the 500s are intentional, but there may be something odd with our setup that is causing them.
    I have a ticket open to investigate the issue further. I have a feeling we won’t be messing with this till after the move, since it’s likely something with the server config.

    Git1.6.4.4 does contain a fix since September, 16th:

    The workaround for Github server that sometimes gave 500 (Internal server error) response to HEAD requests in 1.6.4.3 introduced a regression that caused re-fetching projects over http to segfault in certain cases due to uninitialized pointer being freed.

    But mssysgit has yet to release (September 21th) any new build since the original 1.6.4 late July. (They are probably waiting for 1.6.5 or 1.7)

    • 0