CODEWITHSUNDEEP
gitclone
gct
gct

Reputation: 14573

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.

Upvotes: 57

Views: 109872

Answers (13)

Burhanuddin Rashid
Burhanuddin Rashid

Reputation: 5370

The way I found to fix this is to first use HTTP/1.1 and then increase the post buffer size.

Use HTTPS/1.1

git config --global http.version HTTP/1.1

And then increase the buffer size using

git config --global http.postBuffer 2038500000

However, the trick is to increase the buffer based on the bytes mentioned in the error message that says it cannot download. For example, the git error looks like this:

    Receiving objects:   5% (28560/532810), 19.44 MiB | 336.00 KiB/s
    error: RPC failed; curl 18 transfer closed with outstanding read data remaining
    error: 5319 bytes of body are still expected
    fetch-pack: unexpected disconnect while reading sideband packet
    fatal: early EOF
    fatal: fetch-pack: invalid index-pack output

Here, the line error: 5319 bytes of body are still expected mentions 5319 bytes. So, keep increasing the buffer size until it gets small enough, i.e., zero, to get this working.

git config --global http.postBuffer {additionalbytes}

Upvotes: 1

Are Butuv
Are Butuv

Reputation: 312

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

Upvotes: 1

Starfish
Starfish

Reputation: 85

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.

Upvotes: 1

davenpcj
davenpcj

Reputation: 12684

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.

Upvotes: 4

Lasse Lindqvist
Lasse Lindqvist

Reputation: 41

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.

Upvotes: 0

GreenMoose
GreenMoose

Reputation: 331

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

Upvotes: 0

Flávio H. Ferreira
Flávio H. Ferreira

Reputation: 311

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

Upvotes: 3

mpmeyer
mpmeyer

Reputation: 6944

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.

Upvotes: 3

andywu
andywu

Reputation: 141

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.

Upvotes: 14

Martin
Martin

Reputation: 541

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

Upvotes: 21

Jim Geurts
Jim Geurts

Reputation: 20419

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

Upvotes: -1

Nicolai Josuttis
Nicolai Josuttis

Reputation: 41

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:

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

Upvotes: 4

ivan_pozdeev
ivan_pozdeev

Reputation: 36028

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.

Upvotes: 2

Related Questions