56

When fetching or pulling from git repositories, or cloning a repository, I get to this point: 

remote: Counting objects: 6666, done.
remote: Compressing objects: 100% (5941/5941), done.
Receiving objects:  23% (1534/6460), 11.68 MiB | 23 KiB/s

And it hangs. The 23%/number of objects isn't a given, it ranges from single digits to up to the 60s, it seems. Also the speed for download listed freezes -- it's not like it slowly crawls down towards zero.

The guy I sit next to has no issues, so it's not a router problem. We use beanstalk for our work repositories, but I have the issue from beanstalk and github (although occaisonally it seems a github one will finish).

The problem has only seemed to crop up since upgrading to Mountain Lion and updating Xcode. I've wiped git (including XCode's) and tried installing it with homebrew. That didn't work, so I removed it and tried with their provided Mac installation package which also didn't fix the issue.

Beanstalk provides SSH urls for the git repository, but I've had no issues with connecting via SCP or SSH to servers that I've done work on.

This is killing my workflow so any help would be much appreciated!

gabeb
  • 669
  • 1
  • 6
  • 8
  • You try a new repository clone when you wiped git or has this been the same local repo each time? – Christopher Aug 13 '12 at 20:51
  • Forgot to say that -- it's both with fetch on already existing ones and trying to clone new repos – gabeb Aug 13 '12 at 20:55
  • Does the same error apply to every git repository, or just this particular codebase? For example, if you clone [git's source,](https://github.com/git/git) does it exhibit similar symptoms? – Christopher Aug 13 '12 at 21:02
  • Is this because of another app? (an anti-virus for instance, like in http://openforum.sophos.com/t5/Sophos-Anti-Virus-for-Mac-Home/Sophos-Causing-Mountain-Lion-to-Hang-Spinning-beach-balls-and/td-p/8195), or do you have one component which is known to hang in its current version with Mountain Lion (see http://roaringapps.com/search:site/q/hang) – VonC Aug 14 '12 at 06:02
  • I did have Sophos, which I removed. I've gone through and cleaned out everything, so there's no other applications open, and I cleared out as many background processes as I could. Same issue occurs. – gabeb Aug 14 '12 at 14:21
  • Any solution you found? I am facing exact same problem while cloning mediawiki sources. – Raj Pawan Gumdal Sep 22 '12 at 08:08
  • I ended up wiping my system and going back to Lion. Only other thing I'd suggest trying is cloning with "--depth 1" – gabeb Sep 25 '12 at 19:35

6 Answers6

25

VMware on NAT had this problem for me. Changing it to Bridged (replicate the state) fixed the issue.

Anand Rockzz
  • 6,072
  • 5
  • 64
  • 71
  • Thanks. I can't believe I lost so many hours trying to work around a Github servers limitation, when the solution was in reality so easy... My problem happened when cloning the CocoaPods specs repo, so I figured it was related to https://stackoverflow.com/questions/23755974/cocoapods-pod-install-takes-forever ... It was not, just a network issue. – Sébastien Dec 07 '17 at 10:30
12

Looks similar to mine problem. Git seemed to hang on fetch or push after a certain short amount of time. I can advice you to put in ~/.ssh/config:

Host *

ServerAliveInterval 60

I have a MBP with also mountain lion. I hope this timeout is the cause for your problem. (After thirty or forty minutes or so, I noticed that it continued.)

agold
  • 6,140
  • 9
  • 38
  • 54
driek
  • 159
  • 1
  • 4
10

Try to check your network connection. Maybe there is a garbage in the routing table. Maybe broken port on your router or your computer's network interface problem. Try to ping server from which you are cloning git repo, maybe link between your computer and this server is unstable.

cjayho
  • 545
  • 4
  • 7
  • 4
    I had the same issue and your suggestion worked. I pinged github.com -t and clone started receiving the objects. – ceebreenk Nov 19 '14 at 20:06
  • Unfortunately this didn't work for me. The clone for any repo on github is still stuck at a certain percentage... – xji Dec 15 '15 at 07:15
  • For some reason, your MTU might be set too high. Try lowering the MTU in one of the machines, temporarily, to determine if the cause relates to that. – igordc Jan 14 '17 at 12:46
2

On Mac, git fetch should be more resistant to this kind of issue, with Git 2.22 (Q2 2019): On platforms where "git fetch" is killed with SIGPIPE (e.g. OSX), the upload-pack that runs on the other end that hangs up after detecting an error could cause "git fetch" to die with a signal, which led to a flakey test.
"git fetch" now ignores SIGPIPE during the network portion of its operation (this is not a problem as we check the return status from our write(2)s).

See commit 1435889 (03 Mar 2019), and commit 37c8001 (05 Mar 2019) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 27cdbdd, 20 Mar 2019)

fetch: ignore SIGPIPE during network operation

The default SIGPIPE behavior can be useful for a command that generates a lot of output: if the receiver of our output goes away, we'll be notified asynchronously to stop generating it (typically by killing the program).

But for a command like fetch, which is primarily concerned with receiving data and writing it to disk, an unexpected SIGPIPE can be awkward. We're already checking the return value of all of our write() calls, and dying due to the signal takes away our chance to gracefully handle the error.

On Linux, we wouldn't generally see SIGPIPE at all during fetch. If the other side of the network connection hangs up, we'll see ECONNRESET.
But on OS X, we get a SIGPIPE, and the process is killed.

Let's ignore SIGPIPE during the network portion of the fetch, which will cause our write() to return EPIPE, giving us consistent behavior across platforms.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
2

Resetting the git credentials worked for me.

git config --global credential.helper store
wings
  • 338
  • 4
  • 15
-28

first try to initialize git repository folder by typing

$ git init

it should help

Tim Radcliffe
  • 1,883
  • 2
  • 20
  • 29
Damian Wojcik
  • 1