Github - unexpected disconnect while reading sideband packet

Question

I've got quite interesting problem. I tried to send some projects via bash to repo and recently there was a problem with sending it.

Enumerating objects: 27, done.
Counting objects: 100% (27/27), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (25/25), 187.79 KiB | 9.39 MiB/s, done.
Total 25 (delta 1), reused 0 (delta 0), pack-reused 0
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

The funny part is that 10 min earlier I can send it without any problems.

I tried with getting new repo, creating new file, reinstalling git, git config --global http.postBuffer 524288000 with bigger numbers as well, also https.postBuffer and so on. Also install desktop version the same issue come in.

I've got problems mostly with React apps.

Anyone know the solution ? What could go wrong ?

Still does not find solution. Tried everything, even stupid things like reinstalling system. — Grzegorzz, Mar 26 '21 at 09:20
You could try unstaging the file that you have just committed which is creating problem for the push. The problem for me was two png files. I unstaged them and the problem solved. — Naimul Kabir, Mar 26 '21 at 16:10
https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/22317479#22317479 - also this — tinker-tailor, Sep 29 '21 at 15:44

score 54 · Accepted Answer · edited Apr 28 '22 at 22:17

54

First of all, check your network connection stability.

If there is no problem with network connection try another solution; it may work:

On Linux

Execute the following in the command line before executing the Git command:

export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

On Windows

Execute the following in the command line before executing the Git command:

set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

In addition:

git config --global core.compression 0
git clone --depth 1 <repo_URI>
# cd to your newly created directory
git fetch --unshallow 
git pull --all

For PowerShell users:

As kodybrown said in the comments:

$env:GIT_TRACE_PACKET=1
$env:GIT_TRACE=1
$env:GIT_CURL_VERBOSE=1

edited Apr 28 '22 at 22:17

Henry Ecker

31,792
14
29
50

answered May 04 '21 at 18:32

Hossein Kurd

2,426
2
39
64

3

I started experiencing `send-pack: unexpected disconnect while reading sideband packet` after a push. Repeated attempts would result in high CPU utilisation and finally it would just timeout. I set these three vars and suddenly it just worked. What could be going on here? – Brett Ryan Sep 20 '21 at 00:34
It was the same as @BrettRyan, and just to make it clear that I had to do the three things inside the 'newly created directory'. It was windows. – Brian Hong Oct 01 '21 at 14:02
2

what is the proper way to reverse these changes and can you give a little bit of explanation about what do export GIT_TRACE_PACKET=1 and rest do? – Clay Nov 01 '21 at 12:38
2

For PowerShell users: `$env:GIT_TRACE_PACKET=1`, `$env:GIT_TRACE=1`, and `$env:GIT_CURL_VERBOSE=1`. – kodybrown Dec 17 '21 at 17:25
git config --global core.compression 0 works – focus zheng Jan 22 '22 at 06:10

score 21 · Answer 2 · edited May 31 '22 at 04:25

It might be your network issue. If the network is too slow, then it might disconnect the connection unexpectedly.

If you have good internet and are still getting this message, then it might be an issue with your post buffer. Use this command to increase it:

git config --global http.postBuffer 157286400

According to the documentation at https://git-scm.com/docs/git-config#Documentation/git-config.txt-httppostBuffer:

Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system. For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.

Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard. Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.

So this is only a mitigation in cases where the server is having issues. This is most likely not going to fix push problems to GitHub or GitLab.com.

Doesn't resolve the issue for me . Any comment on what the effect of this should be and why this number? — Wolfgang Fahl, Mar 29 '22 at 16:36
Yeah, a command with such an obscure and specific argument should be explained and understood. — user7778287, May 28 '22 at 18:31

score 6 · Answer 3 · answered Jul 30 '21 at 10:30

6

I didn't want to believe it but after 3 failed clones, switching from a wifi connection (on Mac) to hardwired connection (on Linux) made it work first time. Not sure why!

https://serverfault.com/questions/1056419/git-wsl2-ssh-unexpected-disconnect-while-reading-sideband-packet/1060187#1060187

answered Jul 30 '21 at 10:30

David Newcomb

10,316
3
45
57

I switched from my 5G wireless network to my 2.4G network and it started working again for me – Russ Jackson Jan 13 '22 at 22:10
I switched from wired to wireless and the problem went away - very strange. – Wolfgang Fahl Mar 29 '22 at 16:38

score 4 · Answer 4 · answered May 29 '21 at 19:32

In my case, I had a few files that were over 100MB in size when trying to push my initial commit. Since GitHub apparently doesn't allow this, you get an error "unexpected disconnect while reading sideband packet fatal: the remote end hung up unexpectedly".

Using git rm was not enough, I had to start all over again with git init, git add, git commit and git push to resolve the issue.

cxxl · Answer 5 · 2022-03-04T16:15:45.457

I had the same problem. I have a repo with 20000 files, the whole repo is about 5 GB in size, and some files are 10 MB in size. I could commit to the repo without problems and I could clone without problems (it took a while, though). Yet, every other time I pulled this repo to my machine I got

remote: Enumerating objects: 1359, done.
remote: Counting objects: 100% (1359/1359), done.
remote: Compressing objects: 100% (691/691), done.
remote: Total 1221 (delta 530), reused 1221 (delta 530), pack-reused 0
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

What finally helped was a this tip. Go to your user directory and edit .git/config and add:

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

Voilá. No more errors.

score 3 · Answer 6 · answered Jun 23 '21 at 05:01

3

If you are using SSH URLs, you can try the following, it worked for me the two times I had the same issue:

Switch to HTTPS origin URL: git remote set-url origin https://github.com/<your_repo>
Do the push. It should not fail now.
Switch back to SSH: git remote set-url origin git@github.com:<your_repo>

I'm still not sure what is the cause of the issue. This is just a work around.

answered Jun 23 '21 at 05:01

pau.moreno

4,059
3
31
37

This worked perfectly for me. Thank you! – cautionbug Dec 28 '21 at 23:10
This worked for me - hooray! – jurgenizer Feb 24 '22 at 14:11

score 2 · Answer 7 · answered May 07 '21 at 13:36

2

In my case I got this error with the first commit to a new repo.

I just deleted the .git folder and then added a few files at a time, committing with each addition.

I managed to add everything back, without running into the same error.

answered May 07 '21 at 13:36

Andrew Swift

2,137
3
32
48

kodybrown · Answer 8 · 2021-12-17T18:24:35.047

1

I tried the suggestions above, without success.

It turns out my issue was path length. I don't know if it was the number of nested directories (which are plentiful) or overall path length (path + file).

I cloned at the root of my drive and it worked (yes, on Windows 10).

UPDATE: To clarify, I had to clone to the root of my drive, using the accepted answer.

edited Dec 17 '21 at 18:24

answered Dec 17 '21 at 17:40

kodybrown

2,107
26
22

score 0 · Answer 9 · answered May 26 '21 at 15:04

I beleive you send your projects via https, not ssh. Try to use

ssh://git@host:port/path/name.git

Check if ssl verification in .gitgonfig is turned on

sslVerify = true

If you do not have SSH keys, generate them and add to your remote. Here example for BitBucket:

https://confluence.atlassian.com/bitbucketserver076/creating-ssh-keys-1026534841.html

https://confluence.atlassian.com/bitbucketserver076/ssh-user-keys-for-personal-use-1026534846.html

Accept key during connection

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

score -5 · Answer 10 · answered Jun 20 '21 at 13:30

-5

I had this error cause of miss config norton 360 (firewall/app blocker). Set norton 360 to default settings and then it works.

answered Jun 20 '21 at 13:30

Malte K

1
1

score -6 · Answer 11 · answered Apr 16 '21 at 09:29

-6

I think Try Different Network That and see Problem Still Occurred. You face this problem Because of low Connectivity Of Internet.

answered Apr 16 '21 at 09:29

yash sanghavi

337
2
5

2

Even for local network? I've faced this problem while mirroring repository with several large objects... Still has no solution. – pyhedgehog Apr 22 '21 at 12:47

Github - unexpected disconnect while reading sideband packet

11 Answers11

On Linux

On Windows

For PowerShell users:

Linked

Related