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

Answer 2

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 3

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. You change the url from ssh [email protected]: to https://github.com/ on your remote.

Answer 4

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.