git clone fails with "index-pack" failed?

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.

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

Does "git gc" complain?

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.

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

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.

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.

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.

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

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

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

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.

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.

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