Github-读取边带数据包时意外断开

我有个很有趣的问题。 我试图发送一些项目通过 bash 回购,最近有一个发送它的问题。

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

有趣的是,10分钟前,我可以发送它没有任何问题。

我尝试过获取新的 repo、创建新文件、重新安装 git、使用更大号码的 git config --global http.postBuffer 524288000以及 https.postBuffer 等。同样安装桌面版也有同样的问题。

我的问题主要是反应应用程序。

有人知道解决办法吗? 能出什么问题呢?

126056 次浏览

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

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

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

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 this error cause of miss config norton 360 (firewall/app blocker). Set norton 360 to default settings and then it works.

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.

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

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

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

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.

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.

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.

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.

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

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