Github - unexpected disconnect while reading sideband packet

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 ?

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

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.

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

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.

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.

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

1. Switch to HTTPS origin URL: git remote set-url origin https://github.com/<your_repo>
2. Do the push. It should not fail now.
3. Switch back to SSH: git remote set-url origin [email protected]:<your_repo>

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

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.

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.

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:

> 1. https://confluence.atlassian.com/bitbucketserver076/creating-ssh-keys-1026534841.html > 2. 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

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

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