Transfer closed with outstanding read data remaining ошибка

Я сталкиваюсь с этой ошибкой, когда пытаюсь клонировать репозиторий из GitLab (GitLab 6.6.2 4ef8369):

remote: Counting objects: 66352, done.
remote: Compressing objects: 100% (10417/10417), done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Затем клон прерывается. Как мне этого избежать?

нужно отключить сжатие:

git config --global core.compression 0

тогда вам нужно использовать мелкий клон

git clone --depth=1 <url>

тогда самый важный шаг — это cd в ваш клонированный проект

cd <shallow cloned project dir>

теперь деактивируйте клон, шаг за шагом

git fetch --depth=N, with increasing N

например.

git fetch --depth=4

затем,

git fetch --depth=100

затем,

git fetch --depth=500

вы можете выбрать, сколько шагов вы хотите, заменив это N,

и, наконец, загрузите все оставшиеся версии, используя,

git fetch --unshallow 

проголосуйте за, если это вам поможет 🙂

Проблемы с сетевым подключением.
Может быть, из-за постоянного тайм-аута соединения.
Лучший способ — перейти в другую сеть.

Эти шаги сработали для меня: использование git://вместоhttps://

Как упоминалось выше, прежде всего запустите команду git из bash, добавив вначале расширенные директивы журнала: GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ...

Например, GIT_CURL_VERBOSE=1 GIT_TRACE=1 git -c diff.mnemonicprefix=false -c core.quotepath=false fetch origin
это покажет вам подробную информацию об ошибке.

У меня эта проблема возникла из-за конфигурации прокси. Я добавил ip git server в исключение прокси. Сервер git был локальным, но переменная среды no_proxy была установлена ​​неправильно.

Я использовал эту команду, чтобы определить проблему:

#Linux:
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

Взамен была «авторизация прокси», так как сервер git не должен проходить через прокси. Но настоящей проблемой был размер файлов, определяемый правилами прокси.

Для меня проблема заключалась в том, что соединение закрывается до завершения всего клона. Я использовал Ethernet вместо Wi-Fi. Тогда это решает для меня

Эта ошибка чаще возникает при медленном или проблемном подключении к Интернету. Я подключил с хорошей скоростью интернета, тогда он работает отлично.

Эта проблема возникает, когда у вас проблема с прокси-сервером или медленная сеть. Вы можете использовать глубинное решение или

git fetch --all  or git clone 

    

Если это дает ошибку curl 56 Recv failure, загрузите файл через zip или укажите имя ветки вместо —all

git fetch origin BranchName 

Изменение протокола git clone, чтобы попробовать.

например, эта ошибка произошла, когда «git clone https: // xxxxxxxxxxxxxxx «

вы можете попробовать с «git clone git: // xxxxxxxxxxxxxx», тогда может быть хорошо.

Эти шаги работают для меня:

cd [dir]
git init
git clone [your Repository Url]

Надеюсь, это сработает и для вас.

Issue

I have been trying to git push some files into a repo I just created, but it keeps failing.

I’ve already tried changing http.version from HTTP/2 to HTTP/1.1 (I’ve tried both) and I also increased the http.postBuffer and http.maxRequestBuffer size. Most fixes I found online recommend changing one or both of these.

The largest file in my local working directory is 24.6 MB (excluding a .pack file) so I don’t have to use Git LFS.

Here is some of the output of git config --list:

diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager-core
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
core.editor="C:UsersusernameAppDataLocalProgramsMicrosoft VS CodeCode.exe"
--wait
core.longpaths=true
core.compression=0
gui.recentrepo=C:/Users/username/path/to/myRepo
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
...
http.postbuffer=30000000
http.version=HTTP/1.1
http.maxrequestbuffer=300000000
credential.helper=wincred
core.bare=false
core.repositoryformatversion=0
core.filemode=false
core.symlinks=false
core.ignorecase=true
core.logallrefupdates=true
remote.origin.url=https://github.com/username/myRepo.git
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.pushurl=https://github.com/username/myRepo.git
branch.main.remote=origin
branch.main.merge=refs/heads/main

And here is the output after git push:

Enumerating objects: 177, done.
Counting objects: 100% (177/177), done.
Delta compression using up to 8 threads
Compressing objects: 100% (168/168), done.
error: RPC failed; curl 18 transfer closed with outstanding read data remaining
send-pack: unexpected disconnect while reading sideband packet
Writing objects: 100% (177/177), 444.10 MiB | 612.00 KiB/s, done.
Total 177 (delta 5), reused 177 (delta 5), pack-reused 0
fatal: the remote end hung up unexpectedly
Everything up-to-date

I am using no antivirus/firewall other than Windows Defender.

Please help.

Solution

In my situation, I was trying to push too large a payload. According to this article, «Because github does not allow a single push larger than 2GB you can push it in batches. Split the push into part1, part2…»

My solution was to break up the payload into several commits and push a couple at a time. Depending on your situation, you could try writing a shell script to push incrementally up to HEAD if you have commit history on your repo. I didn’t end up doing that but instead, I made ample use of matching patterns with multiline git add commands to select the files I wanted for each push.

Answered By – michen00

This Answer collected from stackoverflow, is licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0