fatal: early EOF fatal: index-pack failed

Question

I have googled and found many solutions but none work for me.

I am trying to clone from one machine by connecting to the remote server which is in the LAN network.
Running this command from another machine cause error.
But running the SAME clone command using git://192.168.8.5 ... at the server it's okay and successful.

Any ideas ?

user@USER ~
$ git clone  -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed

I have added this config in .gitconfig but no help also.
Using the git version 1.8.5.2.msysgit.0

[core]
    compression = -1

I faced this issue for 2-3 day when i was trying to clone from VPN. in my case issue was network bandwidth. i fixed by cloning in high speed network. — Avijit Nagare, Feb 01 '17 at 08:54
I got this error because my friends not know git so well and push a lot of images into the repository! =)) — Clite Tailor, Nov 19 '17 at 13:01
I also got the same error. I am using a fiber optic connection (40Mbps download speed). And no large files (like images/videos) in my repository too. Nevertheless still getting the same error. — Pawara Siriwardhane, Mar 07 '21 at 03:31
Seems like a memory issue my workaround was to clone via http instead which doesn't seems to suffer those issues. Example : git clone http://192.168.8.5/butterfly025.git — Benpaper, Jun 22 '21 at 15:07
@William : You tagged the question with _cygwin_. I am using Cygwin with git 2.31.1 and never had problems so far, even with large repos on slower networks. You seem to use a pretty old git version - maybe time for an update? — user1934428, Jan 14 '22 at 12:27
I'm using git bash for Windows, and I got rid of this error by upgrading (by reinstalling): https://git-scm.com/downloads — matthiash, Sep 02 '22 at 18:04
I got this error on Windows WSL2 running Ubuntu. Tried many of the suggestions here. None worked. The only thing that worked for me was to reboot my Windows and restart the WSL2 Ubuntu machine. — Morten Grum, May 15 '23 at 09:04
git config --global core.compression 0 ...this was sufficient to correct the issue for me. — Michael Reilly, May 18 '23 at 20:00
For what it's worth, I finally got it to work on Windows by using `git clone` from a Linux VM, in a shared folder. — Eric Duminil, May 22 '23 at 14:00

score 791 · Accepted Answer · edited Jun 08 '15 at 18:48

791

First, turn off compression:

git config --global core.compression 0

Next, let's do a partial clone to truncate the amount of info coming down:

git clone --depth 1 <repo_URI>

When that works, go into the new directory and retrieve the rest of the clone:

git fetch --unshallow

or, alternately,

git fetch --depth=2147483647

Now, do a regular pull:

git pull --all

I think there is a glitch with msysgit in the 1.8.x versions that exacerbates these symptoms, so another option is to try with an earlier version of git (<= 1.8.3, I think).

edited Jun 08 '15 at 18:48

kurtzmarc

3,110
1
24
40

answered Mar 11 '14 at 05:50

ingyhere

11,818
3
38
52

10

Thank you, this worked great. I had tried changing the http.postbuffer which didn't work, but after doing as stated in this answer, it worked great. I didn't use the "git fetch --depth=2147483647" line, but I used the rest. – Nick Benedict Jun 24 '14 at 13:55
`git clone --depth 1` gives me the error `You must specify a repository to clone.` – Eliza Wilson Jul 17 '14 at 22:46
2

@EthenA.Wilson You need to pass in the remote url for the repository afterwards. E.g. `git clone --depth 1 git@host:user/my_project.git`. – Nathan Gould Aug 27 '14 at 17:44
1

git clone --depth 1 works for me but then when doing git fetch --unshallow throws the initial error at the end.. How can i get the remaining files of the rep? – Jose A. Mar 19 '15 at 11:35
7

@Jose A. -- I experienced this problem when I was on a newer version of msysgit. If you are on msysgit, try an older version (<=1.8.3). Otherwise, try git fetch --depth 1000 (then 2000, etc., increasing incrementally until all the files are pulled). – ingyhere Mar 19 '15 at 15:25
3

@Jose A. -- Also, have a look at this: http://stackoverflow.com/questions/4826639/repack-of-git-repository-fails – ingyhere Mar 19 '15 at 15:29
4

Hi, dear friend. Thank you for your great solution. But the last `git pull --all` not works. Because of `git clone --depth 1` will set fetching range only one branch. So we have to edit .git/config first. – pjincz Jul 09 '16 at 16:11
7

Be aware that this is not a real solution as it will set fetching to only one branch and you might end up in this situation: http://stackoverflow.com/questions/20338500/git-repository-lost-its-remote-branches – wranvaud Oct 19 '16 at 18:59
@William and pjincz: It's as real as it gets. On initial repo clone, Git doesn't create local branches to match remotes because it works off a lean paradigm. You will have to script local branch creation as I suggest in [this post to ensure that all remote branches are created locally](http://stackoverflow.com/a/21591209/325452). Anyway, I wouldn't add this to a clone if you're having problems -- get the repo pulled first, and then worry about syncing branches. – ingyhere Jan 03 '17 at 20:34
1

Works great, but why is `core.compression = 0` such an important factor in ensuring successful transmissions? Shouldn't `core.compression = 0` become default then? (I think git internally compresses nicely, so maybe the problem is compression of compressed data which can actually enlarge the data.) – peschü Feb 09 '17 at 15:55
2

Moreover with `git clone --depth 1 ` followed by `git fetch --unshallow` followed by `git pull --all` I did not get all remote branches. `git branch -a` does not show them, only shows `master`. How can I get other remote branches registered in the unshallowed repo? – peschü Feb 09 '17 at 16:09
1

@peschü: See my answer [here](http://stackoverflow.com/a/21591209/325452). `git branch -r | awk -F'origin/' '!/HEAD|master/{print $2 " " $1"origin/"$2}' | xargs -L 1 git branch -f --track` – ingyhere Feb 11 '17 at 00:12
3

Just disabling compression fixed it for me. – Nic Cottrell Nov 10 '17 at 13:04
I am unable to see all the remote branches when I do `git branch -r`, whereas I am able to see all those branches in normally cloned folder. How do I get all the remote branches? – Nisarg Patil Apr 19 '18 at 12:14
3

Adding to @pjincz comment, and for us the not so versed on git config files, the actual change required to get the `git fetch --all` to work is to change `fetch = +refs/heads/master:refs/remotes/origin/master` to `fetch = +refs/heads/*:refs/remotes/origin/*` ( `master` to `*` ), this line must be below the node `[remote "origin"]`. Close the file and repeat the `git fetch --all` command. Tested with git version `2.19.2.windows.1` – Lorenzo Solano Martinez Nov 27 '18 at 14:35
1

It would be nice if someone could explain the problem and what this solution does to solve it in the answer. – GoGoris Oct 22 '19 at 07:56
I found the SSH protocol is faster than others, E.g. `git clone --depth 1 git@host:user/my_project.git`. – Winter May 21 '20 at 11:40
why turn off the compression though? – helix Jun 19 '20 at 05:04
2

The `core.compression` value is used as a default for all other compression parameters. If there are network issues or server instabilities, while at the same time dealing with massive packs or giant files, compression can be costly in terms of time. When dealing with network instabilities, including retries and potentially timeouts, the extra time cost to compress giant files can presage a timeout. Likewise, delta compression on a misconfigured server with big files can tax memory usage, so disabling compression may rectify misconfiguration by preventing memory bottlenecks. – ingyhere Jun 22 '20 at 06:47
1

This procedure breaks the clone into small, manageable chunks. Git itself ([abstracted as a micro filesystem](https://www.theguild.nl/git-the-object-database/)) consists of blobs, trees and maps holding file commit data. [A `pull` is shorthand for `fetch` then `merge`.](https://stackoverflow.com/questions/9237348/what-does-fetch-head-in-git-mean) If the fetch part is screwed up the merge (actually an unwind onto the new default branch) will fail. A shallow clone creates a skeleton of the repo without the giant history but including current files. Later steps pull down the larger file history. – ingyhere Jun 22 '20 at 07:17
Because this still occurs I thought I'd add that dmesg pointed th way in my case... out of memory (which occured during decompressing delta packs). I added a swp file on my ssd attached to my odroid and rocked away. Yes, their was considerable context switching, bu it worked. The solution in this article works better. – uDude Oct 17 '20 at 07:15
A minor point, but after the git clone you have to cd into the repo directory before doing the git fetch. – Ron HD Jan 21 '21 at 05:00
1

first line *git config --global core.compression 0* worked well for me – kplshrm7 Oct 04 '21 at 07:01
1

This works great, but afterwards removing the depth was helpful. This can be done by editing ```.git/config``` and changing the fetch line back to ```fetch = +refs/heads/*:refs/remotes/origin/*```, which will have the stars listed as master. – The Thirsty Ape Dec 08 '21 at 17:11
After editing .git/config and changing the fetch list to fetch = +refs/heads/*:refs/remotes/origin/* worked on me too. Thanks to @ingyhere – Sattar Hummatli Feb 09 '22 at 14:24
1

For me it was enough to just disabling compression. I had over 50k files in the git repository – Magnetic_dud Jun 27 '22 at 10:41
I got ```fatal: not a git repository (or any of the parent directories): .git``` after running ```git fetch --depth=2147483647``` – Khandelwal-manik Sep 30 '22 at 09:29
I am getting the below error when I run "get fetch --unshallow" fetch-pack: unexpected disconnect while reading sideband packetsB/s fatal: early EOF fatal: fetch-pack: invalid index-pack output – Siddarth Aug 29 '23 at 17:42

score 205 · Answer 2 · answered Mar 30 '15 at 20:06

205

This error may occur for memory needs of git. You can add these lines to your global git configuration file, which is .gitconfig in $USER_HOME, in order to fix that problem.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

answered Mar 30 '15 at 20:06

bhdrkn

6,244
5
35
42

This worked for me - although I still needed several attempts, but without this change abort came at 30%, afterwards at 75%... and once it went up to 100% and worked. :) – peschü Mar 15 '17 at 06:33
still not working for me `remote: Enumerating objects: 43, done. remote: Counting objects: 100% (43/43), done. remote: Compressing objects: 100% (24/24), done. error: inflate returned -55/26) fatal: unpack-objects failed ` – Jeevan Chaitanya Nov 07 '19 at 09:21
5

Works for me. But set 8096m for all properties. – Mykola Shorobura Feb 08 '20 at 09:02
This problem happened frequently for me on Windows 10 with Git 2.25.0. I found that if I did `git pull` from the remote machine repeatedly it would occasionally succeed. But what a nuisance. Then I discovered that if you run `git daemon` from within the built-in Windows Bash prompt it works 100% with no workaround needed. – Stefan Feb 15 '20 at 15:30
Are these configured on the server machine or the client machine? – M-Pixel Jun 04 '20 at 23:10
1

@M-Pixel It should be added to client's `.gitconfig`. – bhdrkn Jun 07 '20 at 20:03
This worked for me. Context of my problem was I was running three docker containers that were jenkins runners. They were all doing git init then git fetch at the same time. – solstice333 Sep 01 '21 at 23:14
Worked for me but not on the first try. I managed to clone fully in my fourth try when noone is using wifi at midnight. – Onat Korucu Feb 27 '22 at 22:13
My 64-bit Git v2.37.1 on Windows 11 doesn't let me set `core.packedGitLimit`, `core.packedGitWindowSize`, and `pack.packSizeLimit` to anything over `4095m`, but using this value and `8096m` for the `pack.deltaCacheSize` and `pack.windowMemory` options fixed the problem. Disabling compression and doing a shallow clone did not work. In my case, Git failed to clone a Pantheon.io repo. – CodeManX Feb 28 '23 at 15:35

score 56 · Answer 3 · edited Sep 23 '18 at 10:56

56

finally solved by git config --global core.compression 9

From a BitBucket issue thread:

I tried almost five times, and it still happen.

Then I tried to use better compression and it worked!

git config --global core.compression 9

From the Git Documentation:

core.compression
An integer -1..9, indicating a default compression level. -1 is the zlib default.
0 means no compression, and 1..9 are various speed/size tradeoffs, 9 being slowest.
If set, this provides a default to other compression variables, such as core.looseCompression and pack.compression.

edited Sep 23 '18 at 10:56

lucidbrot

5,378
3
39
68

answered Apr 29 '18 at 03:02

Jacky

1,645
1
14
16

5

Needed to run `git repack` in combination with this solution and then it worked. – erikH Oct 19 '18 at 13:59
This works for me too, through VPN and corporate proxy. `--compression 0` did not work nor did all the `.gitconfig` changes suggested above. – Terrence Brannon Dec 09 '19 at 22:33
Probably [changing the config parms here](https://stackoverflow.com/a/29355320/325452) (to reduce size of transferred data) would do the job, alternately. – ingyhere Aug 06 '20 at 17:52
`git config --global core.compression 9 repack` worked. – hafiz031 Feb 16 '22 at 10:48

score 46 · Answer 4 · edited Jan 07 '19 at 11:14

46

As @ingyhere said:

Shallow Clone

First, turn off compression:

git config --global core.compression 0

Next, let's do a partial clone to truncate the amount of info coming down:

git clone --depth 1 <repo_URI>

When that works, go into the new directory and retrieve the rest of the clone:

git fetch --unshallow

or, alternately,

git fetch --depth=2147483647

Now, do a pull:

git pull --all

Then to solve the problem of your local branch only tracking master

open your git config file (.git/config) in the editor of your choice

where it says:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

change the line

fetch = +refs/heads/master:refs/remotes/origin/master

to

fetch = +refs/heads/*:refs/remotes/origin/*

Do a git fetch and git will pull all your remote branches now

edited Jan 07 '19 at 11:14

henrycarteruk

12,708
2
36
40

answered Oct 30 '18 at 15:42

cmpickle

810
11
10

2

It works, but I left compression to 9 not 0 which failed. – metablaster Apr 16 '20 at 16:21
You could also do this: `git branch -r | awk -F'origin/' '!/HEAD|master/{print $2 " " $1"origin/"$2}' | xargs -L 1 git branch -f --track` followed by `git fetch --all --prune --tags` and `git pull --all`. It will set all remote tracking branches locally. – ingyhere Aug 06 '20 at 17:48
Changing from `fetch = +refs/heads/*:refs/remotes/origin/*` to `fetch = +refs/heads/devel:refs/remotes/origin/devel` did it for me. Yes, I did the reverse and at our company we use "devel" for our main branch name – Cezary Drożak Apr 28 '22 at 13:28
Clone was passed, but the error appears at fetch. Error fixed by set compression to 9. – Valentin Safonnikov Sep 30 '22 at 10:37
```for i in `seq 100 100 30000`; do git fetch --depth=$i; done``` did the trick for me (max seq value was chosen about the amount of available commits), since git fetch --unshallow still failed. Let it run until the output only shows: `remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0` again and again. Was the only way that worked for me on Banana Pi M2+ with armbian cloning neovim. – Daniel Bişar Dec 16 '22 at 07:41

score 24 · Answer 5 · answered Sep 28 '20 at 06:45

24

I was getting the same error, on my side i resolved by running this command, In windows it has some memory issue.

git config --global pack.windowsMemory 256m

answered Sep 28 '20 at 06:45

Umair Iqbal

1,405
2
14
24

score 18 · Answer 6 · answered Aug 04 '17 at 05:57

18

In my case this was quite helpful:

git clone --depth 1 --branch $BRANCH $URL

This will limit the checkout to mentioned branch only, hence will speed up the process.

Hope this will help.

answered Aug 04 '17 at 05:57

sMajeed

323
4
10

Tugay İlik · Answer 7 · 2022-11-10T11:59:02.753

16

I faced this problem with macOS Big Sur M1 Chip and none of the solutions worked for me.

Edit: Works as a solution for M2 Chip aswell.

I solved it by increasing ulimits below.

ulimit -f 2097152
ulimit -c 2097152
ulimit -n 2097152

Running the commands above, will be valid for only current terminal session, so first run this and then clone the repository.

edited Nov 10 '22 at 11:59

answered Aug 04 '21 at 14:51

Tugay İlik

3,688
1
14
21

score 15 · Answer 8 · answered Nov 21 '14 at 17:25

15

I tried all of that commands and none works for me, but what works was change the git_url to http instead ssh

if is clone command do :

git clone <your_http_or_https_repo_url>

else if you are pulling on existing repo, do it with

git remote set-url origin <your_http_or_https_repo_url>

hope this help someone!

answered Nov 21 '14 at 17:25

elin3t

1,881
1
24
29

1

This question is really about the error message in the output above when there's a problem syncing giant chunks of files from a connected repo. You're saying that cutting over to https from ssh allowed the clone to finish? – ingyhere Dec 11 '14 at 01:48
2

Yes! That work for me, I have a 4gb+ repo and the only one solution I got that work was that! – elin3t Dec 11 '14 at 03:17
2

I'd really like to know _why_ this worked. Is there something in the SSH protocol that chokes on large objects that HTTPS does not? Is this a transport layer issue? – bdetweiler Dec 18 '18 at 13:55
A long time I did above (switch to HTTPS); today I noticed that there was a middle-man-attack, and if I use VPN the SSH works just fine (without HTTPS need). – Top-Master Jul 27 '22 at 18:49

score 10 · Answer 9 · answered Jan 07 '15 at 22:42

10

I got this error when git ran out of memory.

Freeing up some memory (in this case: letting a compile job finish) and trying again worked for me.

answered Jan 07 '15 at 22:42

André Laszlo

15,169
3
63
81

For me, there wasn't much memory available, freeing some up and retrying solved it. – Martin Cassidy Jan 15 '15 at 18:23

score 8 · Answer 10 · answered Jan 19 '15 at 15:06

In my case it was a connection problem. I was connected to an internal wifi network, in which I had limited access to ressources. That was letting git do the fetch but at a certain time it crashed. This means it can be a network-connection problem. Check if everything is running properly: Antivirus, Firewall, etc.

The answer of elin3t is therefore important because ssh improves the performance of the downloading so that network problems can be avoided

Switched to a different network, and then it finally worked. — YTG, Jan 17 '21 at 14:51

score 7 · Answer 11 · answered Sep 11 '19 at 02:44

Setting below's config doesn't work for me.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

As previous comment, it might the memory issue from git. Thus, I try to reduce working threads(from 32 to 8). So that it won't get much data from server at the same time. Then I also add "-f " to force to sync other projects.

-f: Proceed with syncing other projects even if a project fails to sync.

Then it works fine now.

repo sync -f -j8

Michał Jaroń · Answer 12 · 2023-06-12T19:47:01.970

It's confusing because Git logs may suggest any connection or ssh authorization errors, eg: ssh_dispatch_run_fatal: Connection to x.x.x.x port yy: message authentication code incorrect, the remote end hung up unexpectedly, early EOF.

Server-side solution

Let's optimize git repository on the server side:

Enter to my server's git bare repository.
Call git gc.
Call git repack -A

Eg:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc
git repack -A

Now I am able clone this repository without errors, e.g. on the client side:

git clone git@my_server_url.com:my_repo_name

The command git gc may be called at the git client side to avoid similar git push problem.

If you are an administrator of Gitlab service - trigger Housekeeping manually. It calls internally git gc or git repack.

Client-side solution

Other (hack, client-side only) solution is downloading last master without history:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

There is a chance that buffer overflow will not occur.

score 4 · Answer 13 · answered May 16 '17 at 20:27

Note that Git 2.13.x/2.14 (Q3 2017) does raise the default core.packedGitLimit which influences git fetch:
The default packed-git limit value has been raised on larger platforms (from 8 GiB to 32 GiB) to save "git fetch" from a (recoverable) failure while "gc" is running in parallel.

See commit be4ca29 (20 Apr 2017) by David Turner (csusbdt).
Helped-by: Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit d97141b, 16 May 2017)}

Increase core.packedGitLimit

When core.packedGitLimit is exceeded, git will close packs.
If there is a repack operation going on in parallel with a fetch, the fetch might open a pack, and then be forced to close it due to packedGitLimit being hit.
The repack could then delete the pack out from under the fetch, causing the fetch to fail.

Increase core.packedGitLimit's default value to prevent this.

On current 64-bit x86_64 machines, 48 bits of address space are available.
It appears that 64-bit ARM machines have no standard amount of address space (that is, it varies by manufacturer), and IA64 and POWER machines have the full 64 bits.
So 48 bits is the only limit that we can reasonably care about. We reserve a few bits of the 48-bit address space for the kernel's use (this is not strictly necessary, but it's better to be safe), and use up to the remaining 45.
No git repository will be anywhere near this large any time soon, so this should prevent the failure.

score 4 · Answer 14 · answered Jun 17 '19 at 07:37

A previous answer recommends setting to 512m. I'd say there are reasons to think that's counterproductive on a 64bit architecture. The documentation for core.packedGitLimit says:

Default is 256 MiB on 32 bit platforms and 32 TiB (effectively unlimited) on 64 bit platforms. This should be reasonable for all users/operating systems, except on the largest projects. You probably do not need to adjust this value.

If you want to try it out check if you have it set and then remove the setting:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

score 4 · Answer 15 · answered Jul 11 '20 at 02:04

I had the same problem, I even tried to download the project directly from the website as a zip file but the download got interrupted at the exact same percent.

This single line fixed my problem like a charm

git config --global core.compression 0

I know other answers have mentioned this but, no one here mentioned that this line alone can fix the problem.

Hope it helps.

score 3 · Answer 16 · answered Aug 31 '15 at 10:23

In my case nothing worked when the protocol was https, then I switched to ssh, and ensured, I pulled the repo from last commit and not entire history, and also specific branch. This helped me:

git clone --depth 1 "ssh:.git" --branch “specific_branch”

score 3 · Answer 17 · edited Sep 23 '18 at 13:33

I have the same problem. Following the first step above i was able to clone, but I cannot do anything else. Can't fetch, pull or checkout old branches.

Each command runs much slower than usual, then dies after compressing the objects.

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

This also happens when your ref's are using too much memory. Pruning the memory fixed this for me. Just add a limit to what you fetching like so ->

git fetch --depth=100

This will fetch the files but with the last 100 edits in their histories. After this, you can do any command just fine and at normal speed.

this "answer" should have been a comment on @ingyhere 's answer. — mc0e, Mar 14 '17 at 07:59

score 3 · Answer 18 · edited Sep 18 '20 at 22:40

3

In my case the problem was none of the git configuration parameters but the fact that my repository had one file exceeding the maximum file size allowed on my system. I was able to check it trying to download a large file and getting an "File Size Limit Exceeded" on Debian.

After that I edited my /etc/security/limits.conf file adding et the end of it the following lines:

hard fsize 1000000
soft fsize 1000000

To actually "apply" the new limit values you need to re-login

edited Sep 18 '20 at 22:40

BuZZ-dEE

6,075
12
66
96

answered Mar 06 '20 at 09:10

tpalanques

83
7

This works? Can you let me know what exactly this change do? – Annadate Piyush Jul 29 '20 at 07:36

score 3 · Answer 19 · answered Oct 20 '20 at 06:32

3

I have tried for several times after I set git buffer, as I mentioned in the question, it seems work now.

So if you met this error, run this command:

git config --global http.postBuffer 2M

and then try again for some times.

Reference:

git push error: RPC failed; result=56, HTTP code = 0

answered Oct 20 '20 at 06:32

Akbar Asghari

613
8
19

Why would this affect a `git clone` using the git: protocol? – kfsone Feb 18 '22 at 06:29
I don't know But using this command makes it possible to clone large projects – Akbar Asghari Feb 18 '22 at 09:32

score 3 · Answer 20 · answered Nov 10 '20 at 11:11

Network quality matters, try to switch to a different network. What helped me was changing my Internet connection from Virgin Media high speed land-based broadband to a hotspot on my phone.

Before that I tried the accepted answer to limit clone size, tried switching between 64 and 32 bit versions, tried disabling the git file cache, none of them helped.

Then I switched to the connection via my mobile, and the first step (git clone --depth 1 <repo_URI>) succeeded. Switched back to my broadband, but the next step (git fetch --unshallow) also failed. So I deleted the code cloned so far, switched to the mobile network tried again the default way (git clone <repo_URI>) and it succeeded without any issues.

score 3 · Answer 21 · answered Sep 29 '21 at 23:49

3

For me it worked when I changed the compression to git config --global core.compression 9

This works

answered Sep 29 '21 at 23:49

Syed Munawar Hussain

41
2

score 3 · Answer 22 · answered Mar 22 '22 at 17:29

3

Tried almost all the answers here but no luck.. Finally got it worked by using the Github desktop app, https://desktop.github.com/

Macbook with M1 chip/Monterey not sure if it mattered.

answered Mar 22 '22 at 17:29

androidkc

689
2
7
16

score 2 · Answer 23 · answered Jan 29 '19 at 14:46

Tried most of the answers here, I got the error with the PUTTY SSH Client with all possible constellations.

Once I switched to OpenSSH the error was gone (remove the Environment Variable GIT_SSH and restart the git bash).

I was using a new machine and newest git versions. On many other/older machines (AWS as well) it did work as expected with PUTTY as well without any git configuration.

score 2 · Answer 24 · edited Sep 04 '19 at 09:56

2

None of the solutions above worked for me.

The solution that finally worked for me was switching SSH client. GIT_SSH environment variable was set to the OpenSSH provided by Windows Server 2019. Version 7.7.2.1

C:\Windows\System32\OpenSSH\ssh.exe

I simply installed putty, 0.72

choco install putty

And changed GIT_SSH to

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE

edited Sep 04 '19 at 09:56

heck1

714
5
20

answered Sep 04 '19 at 08:26

careri

61
4

score 2 · Answer 25 · answered Jan 23 '20 at 14:25

Using @cmpickle answer, I built a script to simplify the clone process.

It is hosted here: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

You can run it using the following line:

curl -sL https://git.io/JvtZ5 | sh -s repo_uri repo_folder

webketje · Answer 26 · 2020-05-18T11:28:11.030

Tangentially related and only useful in case you have no root access and manually extract Git from an RPM (with rpm2cpio) or other package (.deb, ..) into a subfolder. Typical use case: you try to use a newer version of Git over the outdated one on a corporate server.

If git clone fails with fatal: index-pack failed without early EOF mention but instead a help message about usage: git index-pack, there is a version mismatch and you need to run git with the --exec-path parameter:

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

In order to have this happen automatically, specify in your ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

score 0 · Answer 27 · answered Aug 16 '16 at 11:56

0

From a git clone, I was getting:

error: inflate: data stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

After rebooting my machine, I was able to clone the repo fine.

answered Aug 16 '16 at 11:56

Paul Sturgess

3,254
2
23
22

score 0 · Answer 28 · answered Dec 02 '17 at 21:32

0

I turned off all the downloads I was doing in the meantime, which freed some space probably and cleared up/down bandwidth

answered Dec 02 '17 at 21:32

Bartłomiej Wach

1,968
1
11
17

GreenMoose · Answer 29 · 2018-05-02T13:46:22.173

0

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

edited May 02 '18 at 13:46

answered May 02 '18 at 13:03

GreenMoose

331
1
5
6

score 0 · Answer 30 · answered Jun 12 '19 at 00:41

0

I've experience the same problem. The REPO was too big to be downloaded via SSH. Just like @elin3t recommended, I've cloned over HTTP/HTTPS and change the REMOTE URL in .git/config to use the SSH REPO.

answered Jun 12 '19 at 00:41

Rodel

147
1
6

score 0 · Answer 31 · answered Jun 20 '19 at 07:50

I got the same issue as below when I run git pull

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Then I checked the git status, There were so many uncommitted changes I fixed the issue by committing and push all the uncommitted changes.

score 0 · Answer 32 · answered Jan 15 '20 at 12:28

I tried pretty much all the suggestions made here but none worked. For us the issue was temperamental and became worse and worse the larger the repos became (on our Jenkins Windows build slave).

It ended up being the version of ssh being used by git. Git was configured to use some version of Open SSH, specified in the users .gitconfig file via the core.sshCommand variable. Removing that line fixed it. I believe this is because Windows now ships with a more reliable / compatible version of SSH which gets used by default.

score 0 · Answer 33 · answered Aug 04 '20 at 20:47

0

In my case, I simply upgraded my version of OpenSSL. The older versions of OpenSSL have vulnerabilities and also do not have the latest algorithms which may be needed. As of today, the command openssl version shows OpenSSL 1.1.1f 31 Mar 2020.

answered Aug 04 '20 at 20:47

Michael Behrens

911
10
8

score 0 · Answer 34 · answered Mar 12 '21 at 17:57

Although not exactly the same setup, but I had this issue on an nfs share mounted on Ubuntu 20.04. I haven't found any solution so I share how I solved it, hoping that I can help someone.

The error message was (sometimes with/without the warning):

warning: die() called many times. Recursion error or racy threaded death!
fatal: premature end of pack file, 29 bytes missing
fatal: premature end of pack file, 24 bytes missing
fatal: index-pack failed

Git shallow clone, disabling compression, etc. didn't solve the issue.

When I mounted the share with nfsvers=4.2 instead of nfsvers=4.0, the problem disappeared.

score 0 · Answer 35 · answered Jan 10 '22 at 17:30

0

just to add a tip here that if your git clone command has a proxy parameter, your proxy server may disconnect your http/s request prematurely due to its own configuration to disallow too large sized http response binary. just fyi.

answered Jan 10 '22 at 17:30

zhoubig

23
1
4

score 0 · Answer 36 · answered Jul 22 '22 at 11:36

Connections problems

That's the most probable reason. Especially if your git is up to date. (You can update your git if not up to date)

1- Check connection is Stable.
2- VPN => Disable it (if used => big culprit)
3- Antivirus & firewalls

VPN VPN VPN => Big culprit

git cache, buffer, and memory and compression

The other answers cover that well.

Would go with https://stackoverflow.com/a/29355320/7668448

To open global config through cli:

git config --global -e

If not then:

https://stackoverflow.com/a/22317479/7668448

score 0 · Answer 37 · answered Jan 31 '23 at 17:18

0

In your local machines directory you might be running out of space. Make extra storage in the machine you are trying to download into and repeat the checkout. Your problem might be as simple as that.

answered Jan 31 '23 at 17:18

Aarthi Rishi

11
2

score 0 · Answer 38 · answered Aug 14 '23 at 08:28

I am facing the issue too, this is my solution:

git fetch --refetch

From the git-fetch help:

Instead of negotiating with the server to avoid transferring commits and associated objects that are already present locally, this option fetches all objects as a fresh clone would

score -1 · Answer 39 · answered Jun 07 '17 at 03:19

If you're on Windows, you may want to check git clone fails with "index-pack" failed?.

Basically, after running your git.exe daemon ... command, select some text from that console window. Retry pulling/cloning, it might just work now!

See this answer for more info.

score -2 · Answer 40 · answered Feb 23 '15 at 15:04

-2

This worked for me, setting up Googles nameserver because no standard nameserver was specified, followed by restarting networking:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

answered Feb 23 '15 at 15:04

Luca Steeb

1,795
4
23
44

score -2 · Answer 41 · answered Mar 11 '16 at 17:32

-2

Make sure your drive has enough space left

answered Mar 11 '16 at 17:32

IndieTech Solutions

2,527
1
21
36

score -4 · Answer 42 · answered Sep 16 '15 at 15:28

-4

None of these worked for me, but using Heroku's built in tool did the trick.

heroku git:clone -a myapp

Documentation here: https://devcenter.heroku.com/articles/git-clone-heroku-app

answered Sep 16 '15 at 15:28

jpadvo

6,031
3
26
30

fatal: early EOF fatal: index-pack failed

42 Answers42

Increase `core.packedGitLimit`

Connections problems

git cache, buffer, and memory and compression

Linked

Related

fatal: early EOF fatal: index-pack failed

42 Answers42

Increase core.packedGitLimit

Connections problems

git cache, buffer, and memory and compression

Linked

Related

Increase `core.packedGitLimit`