windows - Why would git-upload-pack (during git clone) hang?

Question

I've read several other 'git hangs on clone' questions, but none match my environment and details. I'm using git built under cygwin (msys git is not an option) to clone a repo from a Linux host over SSH.

git clone user@host:repo

I've tested against the same host on other platforms, and it works fine, but on this Windows machine the clone hangs indefinitely. I set GIT_TRACE=1 and it looks like the problem is with this command:

'ssh' 'user@host' 'git-upload-pack '''repo''''

My SSH keys are set up correctly: ssh user@host works fine. When I run the command, I get a bunch of output that ends like this:

...
003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start
0000

Then it hangs for 20+ minutes, which is the longest I've waited before killing it.

The server has Git 1.7.11.7 with OpenSSH 5.9p1, while the client has Git 1.7.9 with OpenSSH 6.1p1.

Is that supposed to be the end of the git-upload-pack output? Is this a bug in Git or my configuration?

Answer 1

The upcoming git1.8.5 (Q4 2013) will document more the smart http protocol.
See commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 by Shawn O. Pearce.

With that detailed documentation, the idea would be to monitor the web requests done between your git client and the server, and see if those conforms to what is documented below.

That could help in pinpointing where the service "hangs".

---

The file Documentation/technical/http-protocol.txt insists on:

• the "Smart Service git-upload-pack"

  • Clients MUST first perform ref discovery with '$GIT_URL/info/refs?service=git-upload-pack'.

    C: POST $GIT_URL/git-upload-pack HTTP/1.0
    S: 200 OK
    S: Content-Type: application/x-git-upload-pack-result
    S: Cache-Control: no-cache
    S:
    S: ....ACK %s, continue
    S: ....NAK
    

  • Clients MUST NOT reuse or revalidate a cached reponse.

  • Servers MUST include sufficient Cache-Control headers to prevent caching of the response.
  • Servers SHOULD support all capabilities defined here.
  • Clients MUST send at least one 'want' command in the request body.
  • Clients MUST NOT reference an id in a 'want' command which did not appear in the response obtained through ref discovery unless the server advertises capability "allow-tip-sha1-in-want".

• The "negociation" algorithm

  (c) Send one $GIT_URL/git-upload-pack request:
  C: 0032want <WANT #1>...............................