11

I have a very big git repository and want to clone from it. On one machine (ArchLinux with git version 2.2.2) everything works fine...

Cloning into 'foo'
remote: Counting objects: 2372505, done
remote: Compressing objects: 100% (456914/456914), done.
Receiving objects: 100% (2372505/2372505), 3.81 GiB | 6.20 MiB/s, done.
...

... but on another machine (Ubuntu with git version 2.3.0, also tried with 1.7.0.4), I only see the following:

Cloning into 'foo'
remote: Counting objects: 2372505, done.

and after some hours, it ends with

Write failed: Broken pipe
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Any idea what's the problem?

By the way:

  • The remote end is a gitlab server.
  • I'm using SSH in both cases.
  • The first (working) machine is connected via VPN (100 MBit/s).
  • The second (non-working) machine is in the same gigabit-subnet as the gitlab server.
Ethan Leroy
  • 13,244
  • 5
  • 32
  • 59
  • 1
    Are you behind a firewall? Because, the firewall sometimes breaks the communication that results in this. I do not know how and why. BTW, which version of git are you using? – positron Feb 09 '15 at 08:37
  • No. As already mentioned: The client is in the same subnet as the server. I also thought it could be a problem with the old git version (1.7.0.4) but after an upgrade to 2.3.0 the problem is still there. – Ethan Leroy Feb 09 '15 at 08:53
  • Does this help? http://hungred.com/how-to/gitlab-error-fatal-remote-hung-unexpectedly/ – positron Feb 09 '15 at 09:06
  • This is another problem. I also had this when I installed gitlab one year ago but I already fixed it back then. – Ethan Leroy Feb 09 '15 at 09:34
  • In my case, I had to turn off my WiFi and turn it back on again. Rest of internet was working, including fast.com, but for some reason no GitHub operations were working. – Joshua Pinter Nov 26 '20 at 21:17

3 Answers3

4

Solved! I used a DNS name for connecting to the gitlab server, and what I didn't know: This name has been resolved to the external IP of the same server, so, the server and the client were not in the same subnet.

So, the client connected to the external IP of the server, so the firewall had to NAT it back to the server.

The solution was quite simple: I just added the hostname with the internal ip to the client machine's /etc/hosts file and from that on the clone worked like a charm.

Ethan Leroy
  • 13,244
  • 5
  • 32
  • 59
1

Regarding GitLab, this thread mentions (for a similar error)

I solved that issue (unable to checkout large repo' via HTTP) by editing git/config/unicorn.yml and setting timeout to 120, when it was previously 30, and restarting the gitab service.

If this is not only about the Git hosting server, but about Git itself, then you have other options to try:

Community
  • 1
  • 1
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • I'm not using HTTP for checkout. Furthermore, I don't think it's caused by gitlab, since I am able to clone the repo with other machines. – Ethan Leroy Feb 09 '15 at 09:32
  • @EthanLeroy how about some local Git config then (https://help.openshift.com/hc/en-us/articles/202398650-git-clone-GitURL-may-fail-with-error-fatal-index-pack-failed): `git config pack.windowMemory 10m && git config pack.packSizeLimit 20m ` – VonC Feb 09 '15 at 09:46
  • @EthanLeroy another approach, just for testing: `git in it && git remote add origin && git pull origin master` – VonC Feb 09 '15 at 09:47
  • with `remote add`: Good idea, but same problem. – Ethan Leroy Feb 09 '15 at 11:49
  • with `config pack...`: Wow! Now it also does `Compressing objects` and starts `Receiving objects`, but there it got stuck at 3%. What does it mean? – Ethan Leroy Feb 09 '15 at 11:53
  • @EthanLeroy maybe the ssh connection isn't resilient enough for this operation? (as in http://stackoverflow.com/a/17494901/6309) – VonC Feb 09 '15 at 12:03
  • I set `ServerAliveInterval` to 60, but makes no difference. – Ethan Leroy Feb 09 '15 at 12:14
0

For me, after trying out all suggestions found on the net, it turned out that the VPN connection was connecting and disconnecting constantly. It seems that if there is too many "network outages" or a lossy network, git clone "jams" and eventually you get the Broken pipe-error message.

To debug, if there is any real traffic going on, you can use

iptraf

or 

tcpdump -ni eth0 host github.com

In my case, there was initially a steady flow of 2MB/s, but after a few secs, the underlying connection broke down, and the clone stream never recovered, until I fixed the OpenVPN connection to stay up more stable.

PHZ.fi-Pharazon
  • 620
  • 5
  • 10