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

Answer 1

I was having this same problem after I added some jazz like this to my ssh config in order to set window titles in tmux:

Host *
PermitLocalCommand yes
LocalCommand if [[ $TERM == screen* ]]; then printf "\033k%h\033\\"; fi

getting rid of that fixed my git.

Answer 2

This worked for me, incase it helps someone else.

Check your git remote url. It might hang with git-upload-pack on a trace if your using the wrong url type. change the url from git@github.com: to https://github.com/ on your remote.

Answer 3

An outdated PuTTy can also cause this. Your system might be using plink.exe as GIT_SSH.

You can install the latest development build from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html to make sure this is not the problem.

Answer 4

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>...............................
  

Answer 5

We have faced a similar issue - and we attributed it to the following: Our git repo has a LOT of binary files checked in (multiple versions, over the past 1.5 years of this project). So, we assumed that this was the cause.

To support this theory, we have other code bases that are more recent (and thus do not have so many binary files and their versions) - which do not exhibit this behavior.

Our setup: Git setup on linux, site-to-site VPN between London and India over a T1 line.