ошибка: сбой RPC; передача curl закрыта, остались невыполненные данные чтения

132

Я сталкиваюсь с этой ошибкой, когда пытаюсь клонировать репозиторий из 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

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

До Нху Ви
источник

Ответы:

223

Чаще всего такое случается: у меня медленное интернет-соединение, и мне приходится клонировать прилично огромный репозиторий git. Наиболее частая проблема заключается в том, что соединение закрывается и весь клон отменяется.

Cloning into 'large-repository'...
remote: Counting objects: 20248, done.
remote: Compressing objects: 100% (10204/10204), 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 clone http://github.com/large-repository --depth 1
$ cd large-repository
$ git fetch --unshallow
Хадер М.А.
источник
10
Это единственный ответ, который описывает способ решения проблемы без переключения на SSH. У меня это сработало, спасибо!
Garie
14
Ключевым моментом здесь является --depth 1и --unshallow. Это также работает для получения существующего репо при медленном соединении: git fetch --depth 1then git fetch --unshallow.
Эндрю Т.
1
Для ясности @AndrewT. git fetch --unshallowКоманда справляется с потерей соединения более щадящим способом, чем команда git clone? И вот в чем здесь разница?
Лоуэлл
2
Теперь git fetch --unshallowкоманда RPC failed;
выдает
1
У меня не сработало. Не удалось на git fetch --unshallow. Думаю, мое репо слишком велико даже для такого подхода. Работал только SSH.
Джонатан Кабрера,
60

Через несколько дней, сегодня я решил эту проблему. Создайте ключ ssh, следуйте этой статье:

https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/

Объявить это

  1. Поставщик Git (GitLab, который я использую, GitHub).
  2. Добавьте это к местной идентичности.

Затем клонируйте командой:

git clone username@mydomain.com:my_group/my_repository.git

И никаких ошибок не происходит.

Вышеупомянутая проблема

ошибка: сбой RPC; curl 18 передача закрыта, оставшиеся данные для чтения

из-за ошибки при клонировании по протоколу HTTP ( curlкоманда).

И вы должны увеличить размер буфера:

git config --global http.postBuffer 524288000
До Нху Ви
источник
7
Переход с HTTP на SSH работает для меня. Конфиг http.postBufferне работал.
thangdc94
если ошибка все еще существует, вам следует отредактировать файл конфигурации ssh vi /users/username/.ssh/config и добавить serverAliveInterval 120 и выйти из vi с помощью wq (для сохранения и выхода). Это фактически предотвратит тайм-аут сервера и ошибки разрыва соединения.
Танвир Сингх
это хорошо, но кто-нибудь знает, почему это происходит на 100% клонированных?
workplaylifecycle
Смена http.postBufferсработала у меня - спасибо!
Негар Замири,
Спасибо, у меня это работает, за это решение нужно проголосовать больше :)
Садми
17

Когда я пытался клонировать с пульта, неоднократно возникала одна и та же проблема:

remote: Counting objects: 182, done.
remote: Compressing objects: 100% (149/149), 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 clone https://username@bitbucket.org/repositoryName.git --depth 1
Пурушоттам Падхья
источник
4
что делает --depth 1
Wahdat Kashmiri
Хорошо сработало для меня.
Виджай Джунупалли,
Если исходный репозиторий полный, преобразуйте неглубокий репозиторий в полный, удалив все ограничения, налагаемые мелкими репозиториями. Если исходный репозиторий неглубокий, выберите как можно больше, чтобы текущий репозиторий имел ту же историю, что и исходный репозиторий.
RahmanRezaee
6

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

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 

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

NikhilP
источник
5

Простое решение: вместо клонирования через https клонируйте его через ssh.

Например:

git clone https://github.com/vaibhavjain2/xxx.git - Avoid
git clone git@github.com:vaibhavjain2/xxx.git - Correct
Вайбхав Джайн
источник
Да. Я пользователь Windows.
Vaibhav Jain
5

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

Ян
источник
5

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

Jinwawa
источник
3
Добро пожаловать в Stack Overflow. Пожалуйста, постарайтесь дать более подробный ответ, чтобы любой, кто хочет попробовать ваше решение, смог сделать это легко.
McMutton 05
на самом деле, этот ответ более конкретен, чем следующие в этой ветке ..
xxxvodnikxxx
4

Как упоминалось выше, прежде всего запустите команду 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 это покажет вам подробную информацию об ошибке.

Сергей Гиндин
источник
2

У меня эта проблема возникла из-за конфигурации прокси. Я добавил 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 не должен проходить через прокси. Но настоящей проблемой был размер файлов, определяемый правилами прокси.

Франсиско Эдуардо
источник
2

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

Юреш Карунанаяке
источник
1

Пробовал все ответы здесь. Я пытался добавить кокосы на свою машину.

У меня не было SSH-ключа, спасибо @Do Nhu Vy

https://stackoverflow.com/a/38703069/2481602

И наконец использовал

git clone https://git.coding.net/CocoaPods/Specs.git ~/.cocoapods/repos/master

чтобы окончательно исправить найденную проблему https://stackoverflow.com/a/50959034/2481602

MindBlower3
источник
1

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

Джитендра Ратор
источник
1

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

git fetch --all  or git clone 

    

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

git fetch origin BranchName 
Гаджендер Сингх
источник
-1

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

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

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

Биннань
источник
-6

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

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

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

Вэнь Цзян
источник