144

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 ?

Manuel Allenspach
  • 12,467
  • 14
  • 54
  • 76
Grzegorzz
  • 1,445
  • 2
  • 7
  • 6
  • 6
    Facing the same problem, did you find any solutions? – Naimul Kabir Mar 24 '21 at 18:13
  • 7
    Still does not find solution. Tried everything, even stupid things like reinstalling system. – Grzegorzz Mar 26 '21 at 09:20
  • 1
    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
  • 3
    I tried that also, unfortunately it does not work also – Grzegorzz Mar 28 '21 at 15:49
  • https://stackoverflow.com/questions/21277806/fatal-early-eof-fatal-index-pack-failed/22317479#22317479 - also this – Ulysses Sep 29 '21 at 15:44
  • WTF. This problem is really annoying. GIT is supposed to work fine for huge projects with thousands of contributors. Yet I cannot git clone my repo from the server across the room. Worse, it waits until 100% "completion" until it fails, and you need to start from scratch. – Eric Duminil Apr 20 '23 at 12:22
  • # For Iranian It's a solution that worked for me https://stackoverflow.com/a/76128013/5062890 – Masih Jahangiri Apr 28 '23 at 09:18
  • Beware, if the error starts with `error: RPC failed; curl 92 HTTP/2...`, the solution is this https://stackoverflow.com/a/59474908/3797799 – colinD Jul 13 '23 at 13:30

27 Answers27

122

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
Henry Ecker
  • 34,399
  • 18
  • 41
  • 57
Hossein Kurd
  • 3,184
  • 3
  • 41
  • 71
  • 5
    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
  • 5
    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
  • 3
    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
  • 7
    git config --global core.compression 0 works – focus zheng Jan 22 '22 at 06:10
  • 1
    When I had this problem I had made all the proposed git configuration changes, and the pull still failed. Then after setting the environment variables for tracing the pull succeeded. So this looks like a race condition to me that is avoided by the slowdown caused by the logging output. – stm Jul 20 '22 at 05:46
  • 1
    This worked for me. I was at git clone and got `client_loop: send disconnect: Broken pipe fetch-pack: unexpected disconnect while reading sideband packet fatal: early EOF fatal: fetch-pack: invalid index-pack output` It would be helpful to know why changing these variables would help with a connection problem. – puddles Oct 07 '22 at 05:20
  • 3
    how to revoke the changes? – Baenka Dec 29 '22 at 09:15
  • @Baenka: Close the console? At least it worked for me on Windows. – Eric Duminil Apr 20 '23 at 09:39
  • 4
    To revert this, `unset GIT_TRACE_PACKET GIT_TRACE GIT_CURL_VERBOSE` worked for me. – enadun May 19 '23 at 05:58
  • 1
    ```unset GIT_TRACE_PACKET``` ```unset GIT_TRACE``` ```unset GIT_CURL_VERBOSE``` – Isaac Padberg Jun 30 '23 at 16:54
  • 1
    PWSH: `$env:GIT_TRACE_PACKET=$null;$env:GIT_TRACE=$null;$env:GIT_CURL_VERBOSE=$null` – Dennis Aug 14 '23 at 17:25
  • what are the commands for mac os users bro? – Rohithaditya Aug 26 '23 at 20:51
68

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 (for example) to 150 MiB:

git config --global http.postBuffer 157286400

According to git-config Documentation for http.postBuffer:

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.

Wolf
  • 9,679
  • 7
  • 62
  • 108
Codemaker2015
  • 12,190
  • 6
  • 97
  • 81
  • 6
    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
  • 3
    Yeah, a command with such an obscure and specific argument should be explained and understood. – user7778287 May 28 '22 at 18:31
  • 1
    The quoted text says "this is not, in general, an effective solution" but of the four times I have encountered issues while pushing (large... should probably have used `git-lfs` instead but too late now) repositories this fixed it – lucidbrot Jun 14 '23 at 10:07
  • 2
    For my case, I had too many images that I had to push to the repo. Increasing buffer size worked for me. – Aajinkya Singh Jul 19 '23 at 18:21
  • 1
    This work for me. My case: 600mb connection speed (upload/download). My project size is 28,2MB (49files, 26 directories).. All files size is very little. – Genaut Aug 25 '23 at 18:22
34

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.

cxxl
  • 4,939
  • 3
  • 31
  • 52
29

None of the above worked for me, git config --global pack.window 1 did.

vaind
  • 1,642
  • 10
  • 19
15

git config --global http.version HTTP/1.1

solved the problem for me. I was unable to push large commits in multiple different github repositories earlier.

vishvAs vAsuki
  • 2,421
  • 2
  • 18
  • 19
9

Connection, VPN, Antivirus, Firewall

Most probable reason. Especially if your git is up to date (if not you can update it).

The first thing to try is to check your connection and that it is stable.

My connection is excellent ===> wait Are you using VPN ?

=> Disable it. And try. (VPN's are big culprit for such a problem)

Still doesn't work? ==> Check for antivirus and firewalls.

  • Internet stable.
  • VPN VPN VPN => Big culprit
  • firewall and antivirus
  • git up to date

If that doesn’t work see the below:

Git cache, buffers and memory

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

Open git global config:

git config --global -e

And add those entries:

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

Try to clone again.

If that doesn't work! =>

You can try the partial fetch method and disabling compression:

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

One command at a time

git config --global core.compression 0
git clone --depth 1 <repo_URI>
git fetch --unshallow 

More details are on the link.

Mohamed Allal
  • 17,920
  • 5
  • 94
  • 97
  • 1
    Why are VPNs a culprit for this? I'd prefer not to have to disconnect my VPN each time I want to push – codeananda Nov 09 '22 at 09:15
  • 1
    I used the settings above but I had compression=0 already and `git pull` still gave the above error message. When I dropped the compression=0 line it worked. – 8DH Nov 11 '22 at 10:16
  • 1
    @codeananda i just get to see your question. I wonder. Two things came to my mind after thinking about it. Either something to do with the rotation as this problem only occurs with large repositories. I'll make an experiment with disabling rotation. The second thing is may be something like the MTU notion ref here https://stackoverflow.com/a/61131561/7668448. It seems to be related to ssh ... I'll update the answer in case i find something solid and practical. – Mohamed Allal Dec 13 '22 at 14:16
  • Update: git complains when I try to push big changes with my VPN on. If I push small changes (< 20 LOC) with a VPN on, it usually works fine – codeananda Dec 13 '22 at 15:00
  • yea it's absolutely that. it only doesn't when the size is large. It always work with git and no problem with all repo. First time i encountered that it was the vscode repo. I contacted surfshark vpn support to ask just in case. Ii mentioned those details. Also counting to do the rotation test. Will update the answer if I get anything good. – Mohamed Allal Dec 13 '22 at 18:02
7

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

David Newcomb
  • 10,639
  • 3
  • 49
  • 62
5

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.

Smile4ever
  • 3,491
  • 2
  • 26
  • 34
4

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 git@github.com:<your_repo>

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

pau.moreno
  • 4,407
  • 3
  • 35
  • 37
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.

Andy Swift
  • 2,179
  • 3
  • 32
  • 53
2

For windows

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

git init

and then clone the project you need it worked for me

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.

kodybrown
  • 2,337
  • 26
  • 22
1

Nothing of the above worked, but switching from OpenSSH to plink did work:

$env:GIT_SSH="C:\ProgramData\chocolatey\bin\PLINK.EXE"

My setup is:

  • C:\windows\System32\OpenSSH\ssh.exe (8.1.0.1)
  • C:\Program Files\Git\cmd\git.exe (2.37.3.1)
  • Microsoft Windows [Version 10.0.19044.2604]
Konrads
  • 2,206
  • 2
  • 30
  • 45
1

Adding to a previous solution, what solved the issue for me was to disable jumbo frames on my network, in addition to the mentioned config value.

I have no idea if the problem was my ISP or local (or maybe even Github), but it doesn't hurt to try for whoever reads this.

Eric Aya
  • 69,473
  • 35
  • 181
  • 253
1

On Windows 11, I solved this problem by upgrading build-in OpenSSH which is in C:\Windows\System32\OpenSSH folder.

You can download the latest binaries here: https://github.com/PowerShell/Win32-OpenSSH/releases

See #2012 in the release notes which solves the problem:

v9.2.2.0p1-Beta Latest
This is a beta-release (non-production ready)

This release includes:

Security Fixes:

Upgrade to LibreSSL 3.7.2. Please refer to https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.7.2-relnotes.txt
MSI: change inbound firewall rule that opens port 22 to apply to Private networks only
Non-Security Fixes:

Add U2F/Fido2 keys to the agent from other clients: #1961 - thanks @ddrown!
Fix output codepage after executing scp/sftp/ssh/ssh-keygen command: #2027 - thanks @kemaruya!
Fix early EOF termination when running git fetch over ssh: #2012 - thanks @cwgreene!
Revert mark-of-the-web for SCP/SFTP file downloads: #2029
Mehmet Fide
  • 1,643
  • 1
  • 20
  • 35
0

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
0

None of these options worked for me on Windows when doing the git fetch --unshallow. To correct my instance, I went into the directory and ran git gui to bring up the UI version on Windows. Then I selected Compress Database.

This completed without error, and I was then able to do the git fetch --unshallow with and without compression.

Steven Scott
  • 10,234
  • 9
  • 69
  • 117
  • 4
    This is a placebo: it doesn't solve the problem, it merely makes you wait long enough for the issue causing the problem to have finished. – kfsone Jul 15 '22 at 17:33
0

I tried everything above and nothing worked.

So I created a new repository using Github Desktop (opened as admin) on Windows 11, and I copied all my files from the faulty repo into the new one via the normal file explorer operations. I pushed the new changes to Github (remote) still using the Github desktop app. I then opened the local repo in VScode. I am now using the new repo and everything is fine. I can now push to git successfully after making edits.

AnatuGreen
  • 579
  • 7
  • 14
0

This is a problem sending bits over https protocol. You can configure git to use ssh instead.

First create an ssh-key on your workstation, then copy that key to Github to authenticate your computer without a password. Then configure git to use ssh protocol instead of https.

Create ssh key

No need to repeat Github's excellent instructions here.

Simple way

Use git protocol for the clone command:

git clone git@github.com:repo-name
General method: Configure git to use ssh (git) protocol instead of https

This option is good if you are using GitHub Desktop and don't have direct control over the clone URL.

git config --global url."git@github.com:".insteadOf "https://github.com/"   

For Github enterprise, make your local translations for your instance rather than public github.

After this, you should be able clone without this error.

Merl
  • 303
  • 1
  • 3
  • 11
0

Because of unknown reason previous attempt to install homebrew failed ... u should now uninstall it using following command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/uninstall.sh)"

then re-install using:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

0

I got this problem today out of nowhere — the same repo was working the day before with no problems. I solved it by deleting my SSH key on the Github config panel and adding it again, as described in Github docs. I did not need to create new SSH keys.

Edil
  • 31
  • 5
0

Try pushing from your Vscode's git GUI. It worked for me.

Bravo Stack
  • 111
  • 1
  • 6
0

For me, a quick restart of my router solved the problem. No other configuration changes were needed, but situations may vary.

Nathan Raine
  • 421
  • 7
  • 12
0

I have faced the similar issue and solved by using setting the remote url as SSH one.

git remote set-url origin <SSH URL>

My repo was cloned initially with SSH and then changed to HTTPS caused the problem for me. So, I have set again the remote origin as SSH and it starts working as usual.

rakeeee
  • 973
  • 4
  • 19
  • 44
0

If you are under Windows and the credential manager path did not yield results you might have problems in your local copy of the repository.

You might need to execute some maintenance on it, be careful that the following set of commands will also remove your git stash contents and there is no turning back.

git fetch --prune   // align local state
git branch -vv | grep -i 'gone' | awk '{print $1}' | xargs git branch -D // Delete branches marked as gone by the remote server
git fsck --full // verifies the connectivity and validity of the objects in the database
git reflog expire --expire=now --all // manage reflog information
git repack -a -d -l // pack unpacked objects in the repository
git gc --prune=now --aggressive // cleanup unnecessary files and optimize the local repository

Comments are intentionally in the way of a copy-paste to give you time to read and decide if you want to continue.

This will remove all the local branches marked as deleted by the remote copy, dangling commits and other dead things.

After you have cleaned your local copy you can retry the operation that failed before.

Matteo
  • 1,107
  • 2
  • 27
  • 47
0

All options above didn't solve the issue for me. I noticed that some helped and went past the initial limit, but still stopped halfway.

My issue was that, I was not able to fetch/clone/pull my repos due to some large files in the commit history that exceeded the 100mb mark. Also my slow internet made it impossible to fetch bad repos that still had those commit history to resolve the problem locally before pushing online.

Based on some of the comments that focused on the issue being a network/internet problem, I decided to focus on my SSH config and improve it for performance to see if it could help solve the problem. And Viola!!! Problem solved. I still maintained some of the configurations from previous suggestions, expecially the one related to the .git/config cache settings

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

This is how I updated by SSH confi at .ssh/config :

To improve Git download speed Linux, you can modify the SSH client configuration to optimize the SSH connection. Here are a few configuration options you can consider:

Use a faster SSH algorithm: By default, OpenSSH prioritizes the ssh-rsa algorithm for SSH connections. However, the ecdsa-sha2-nistp256 algorithm is generally faster. You can add the following line to your ~/.ssh/config file to use it:

Host *
  HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa

Enable connection multiplexing: SSH connection multiplexing allows reusing existing SSH connections, which can significantly reduce the overhead of establishing new connections. Add the following lines to your ~/.ssh/config file to enable connection multiplexing:


Host *
  ControlMaster auto
  ControlPath ~/.ssh/control:%h:%p:%r
  ControlPersist yes

Increase SSH connection timeout: In case you have a slow or unstable network, increasing the SSH connection timeout can prevent premature connection terminations. Add the following line to your ~/.ssh/config file to increase the timeout to 60 seconds:

Host *
  ServerAliveInterval 60

Use a faster cipher: You can try using a faster cipher algorithm to improve SSH performance. However, keep in mind that it may require the remote SSH server to support the chosen cipher. For example, to use the aes128-gcm@openssh.com cipher, add the following line to your ~/.ssh/config file:

Host *
  Ciphers aes128-gcm@openssh.com

After making any changes to the SSH client configuration, save the file and try using Git again to see if there is an improvement in download speed.

After assessing all, I combined them and put this at the end of my .ssh/config file:

Host *
  HostKeyAlgorithms ecdsa-sha2-nistp256,ssh-rsa
  ControlMaster auto
  ControlPath ~/.ssh/control:%h:%p:%r
  ControlPersist yes
  ServerAliveInterval 60
  Ciphers aes128-gcm@openssh.com

Remember to exercise caution and be mindful of security implications when modifying SSH configuration options. Some options may require compatibility with the remote SSH server and its configuration.

0

I tried many of the suggestions above, but none worked. I finally upgraded my git client from 2.37 to 2.41 & the problem went away.

Note, I've been getting random "your connection was interrupted" so my PC seems to have issues, which is another story.

Mr Smith
  • 3,318
  • 9
  • 47
  • 85