git clone fails with "index-pack" failed?

user_157525 0
Viewed 93723

So I created a remote repo that's not bare (because I need redmine to be able to read it), and it's set to be shared with the group (so git init --shared=group). I was able to push to the remote repo and now I'm trying to clone it.

If I clone it over the net I get this:

remote: Counting objects: 4648, done.
remote: Compressing objects: 100% (2837/2837), done.
error: git-upload-pack: git-pack-objects died with error.B/s  
fatal: git-upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

I'm able to clone it locally without a problem, and I ran "git fsck", which only reports some dangling trees/blobs, which I understand aren't a problem. What could be causing this? I'm still able to pull from it, just not clone. I should note the remote git version is 1.5.6.5 while local is 1.6.0.4

I tried cloning my local copy of the repo, stripping out the .git folder and pushing to a new repo, then cloning the new repo and I get the same error, which leads me to believe it may be a file in the repo that's causing git-upload-pack to fail...

Edit: I have a number of windows binaries in the repo, because I just built the python modules and then stuck them in there so everyone else didn't have to build them as well. If I remove the windows binaries and push to a new repo, I can clone again, perhaps that gives a clue. Trying to narrow down exactly what file is causing the problem now.

clone git
12 Answers

I have the same problem as you; the error message when I clone i:

Cloning into test...
remote: Counting objects: 6503, done.
remote: Compressing objects: 100% (4519/4519), done.
Connection to git.myhost.im closed by remote host.| 350 KiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

In my case, the reason is that my repository size (200M) is larger than my git server's memory (128M). When I clone from the git server, I use command top on my server, which shows that memory usage is soon over 128M.

When I use another server that has 4G memory, the git clone is all okay. You could also try adding more swap space to your sever.

user_10825980

I ran into this issue, cloning a github repository from github.com, running git 2.13 on SLES 12 SP3. Tried upgrading git to latest (v2.21 at the time), but that did not resolve the issue. Tried setting git config options suggested, and many other options, with no luck.

Ultimately, I did it by hand.

  • created the directory manually.. mkdir somedir
  • Ran git init to set up the directory for GIT.
  • Manually added the github repo as an origin git remote add origin http://github.com/git/git
  • Ran git fetch to grab the pack. This task failed with an error, but left behind the fetched-but-bad pack in .git/objects/pack/tmp_pack_XXXXXX
  • used cat .git/objects/pack/tmp_pack_XXXXXX | git unpack-objects -r to extract all the valid objects.
  • Ran git fetch again to get anything (like branches and tags) missed from the prior attempts. No pack/objects needed because they were all unpacked.
  • Finally, git checkout master, to get HEAD pointing at something real.

I'm not sure it was required for me, but I'd recommend git fsck and git gc after that, which will also trigger git to recreate the packs/indexes.

davenpcj_47770

In my case, Windows Defender was blocking access to the files by git, because I had turned on Ransomware Protection's Controlled folder access. Adding git here (screenshot) to allow access did the trick.

user_133361870
user_3614790

I had this problem or close to it but did not see the solution to my case in any of these threads.

In my case the problem was the firewall. Cloning small repositories worked anyway, but bigger ones failed. So if nothing else helps, firewall settings is worth checking out.

user_80741190

This error could mask these problems:

  • not enough disk space
  • not enough RAM

If the instance with git is low on RAM then you could try to add a swap temporary:

fallocate -l 2G /swap
chmod 600 /swap
mkswap /swap
swapon /swap

when done:

swapoff /swap
rm -f /swap
user_23742200
Related