git clone fails with “index-pack” failed?

Question

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.

Answer 1

The way I solved this problem is this: My git daemon is running on windows, and clients are on other computers.

I found a workaround (but it will only work on windows).

Start git daemon with verbose from cmd.exe:

"C:\Program Files\Git\bin\sh.exe" --login -i -c 'git.exe daemon --verbose  '

Not tested, if it works directly in git bash. Maybe it will.

Then (before starting any clone, pull, fetch,...) select some text in the window (note: "Quick Edit Mode" must be enabled (can be found in: cmd.exe --> Properties (click the top left corner of your cmd window) --> Edit Options)) in which git daemon runs. That will prevent it from printing any further messages in that window.

When the output thread of git daemon is blocked that way, then the error does not happen

Answer 2

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.

Answer 3

Does "git gc" complain?

Answer 4

I had the same problem. My guess also was that this has to do with the fact that I use text/CRLF mode for created files. And indeed, after switching CygWin to UNIX/binary newline mode, everything works fine.

See:

• http://cygwin.com/cygwin-ug-net/using-textbinary.html
• http://www.sourceware.org/cygwin/cygwin-ug-net/using-utils.html#mount

BTW, the easiest way for me to switch the file mode was to edit /etc/fstab to switch from

none /cygdrive cygdrive text,posix=0,user 0 0

to

none /cygdrive cygdrive binary,posix=0,user 0 0

Answer 5

Use GIT_TRACE environment variable to get debug output. Set it to "1" to trace to stderr or an absolute path to trace to file.

Answer 6

I also had problems with cygwin git, the error: fatal: index-pack failed,

I was able to solve it by creating a mount for my projects and setting it to binary mode. since my /c is set to text mode.

Add cygwin's to /etc/fstab:

c:/work/Projects /projects some_fs binary 0 0

run mount -a to mount all drives.

You need to be in /projects to work with cygwin git, /c/work/Projects will fail.

Not sure if this will work for you.

Answer 7

I upgraded my client computer's git source to the same version that the server is running and that fixed this for me.

Answer 8

I've the same problem and I would change my git configs to and that is worked fine:

git config --global pack.packSizeLimit 50m
git config --global pack.windowMemory 50m
git config --global core.compression 9

Answer 9

The git-daemon issue seems to have been resolved in v2.17.0 (verified with a non working v2.16.2.1). I.e. workaround of selecting text in console to "lock output buffer" should no longer be required.

From https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt:

• Assorted fixes to "git daemon". (merge ed15e58efe jk/daemon-fixes later to maint).

Answer 10

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.

Answer 11

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.

Answer 12

I solve this problem by fixing the folder permission:

sudo chmod 777 -R Your_folder