Мерзавец, смертельный: удаленный конец неожиданно завис

Когда я пытался бежать

git push origin master --force

Я только что получил

Counting objects: 2649, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1280/1280), done.
error: RPC failed; result=22, HTTP code = 413 | 116 KiB/s   
fatal: The remote end hung up unexpectedly
Writing objects: 100% (2504/2504), 449.61 MiB | 4.19 MiB/s, done.
Total 2504 (delta 1309), reused 2242 (delta 1216)
fatal: The remote end hung up unexpectedly
Everything up-to-date

Это как-то связано с отсутствием безопасности? Я попытался создать открытый ключ, как в ответе для Fatal: удаленный конец неожиданно завис и запустил его снова, но он все еще не работает. Я на самом деле не использую ключ? Если да, то как мне его использовать?

Это похоже на то, как я могу установить для github по умолчанию ssh, а не https для новых репозиториев . Вероятно, стоит попробовать перейти с протокола http на ssh:

$ git remote add origin git@github.com:username/project.git

Проблема связана с настройками буфера git / https. Для того, чтобы решить это (взято из Git не удается при нажатии на коммит на github )

git config http.postBuffer 524288000

И снова запустите команду

Причина. Превышен размер сообщения по умолчанию для Git.

Решение :

Перейдите к репо.

Выполните следующую команду, чтобы увеличить буфер до 500 МБ после перехода к хранилищу:

git config http.postBuffer 524288000

Вы можете получить такую ​​ошибку

ошибка: не удалось заблокировать файл конфигурации .git / config: нет такого файла или каталога

это потому, что у вас нет локального .git/configфайла. Вы можете заставить его работать этой командой

git config --global http.postBuffer 524288000

Другие решения не работали в моем случае, сборка мусора исправила это для меня:

git gc --aggressive

Вопреки одному из других ответов - у меня была проблема с push через ssh - я переключился на https, и это было исправлено.

git remote remove origin
git remote add origin https://github..com/user/repo
git push --set-upstream origin master

Эта ошибка также может быть вызвана отсутствующими разрешениями на запись в хранилище.

Мой конкретный случай пошел так:

1. Я создал репо с rootпользователем моего сервера (через SSH).
2. Я установил службу git и создал gitпользователя linux, который должен управлять всеми действиями, связанными с git.
3. К тому времени я уже забыл, что rootв первую очередь создается репо с пользователем, и у gitпользователя просто не было прав доступа к файлам для записи чего-либо в репозиторий.

Culprit (в моем случае):
сеть с высокой задержкой.

Это не ответ сам по себе, а скорее наблюдение, которое может помочь другим. Я обнаружил, что эта ошибка иногда появляется в сетях с высокой задержкой (я должен использовать спутниковую антенну для доступа в интернет, например). Скорость сети хорошая, но задержка может быть высокой. Примечание: проблема существует только в определенных сценариях, но я не определил, что это за шаблон.

Временное смягчение:
я переключил сети - я перешел на более медленную сотовую сеть с более низкой задержкой (мой телефон использовался в качестве точки доступа) - и проблема исчезла. Обратите внимание, что я могу сделать это только случайно, потому что подключение к моей ячейке также прерывисто. Плюс использование полосы пропускания увеличивает затраты. Мне также повезло, что у меня есть эта опция для меня. Не все так делают.

Я уверен, что где-то есть какой-то параметр конфигурации, который делает git - или ssh, или curl, или любое другое время ожидания - более терпимым к таким сетям, но я не знаю, что это такое.

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

В нашем случае проблема заключалась в клоне, который написал .git/configфайл, содержащий запись URL, которая была доступна только для чтения. Изменение URL-адреса с ://метода на @метод решило проблему.

Бег git remote -vосветил вопрос какой-то.

Если вы используете git для Windows (и, вероятно, если вы делаете это на компьютере с Windows), и никакие другие исправления здесь не помогли, попробуйте зайти на https://github.com/git-for-. Windows / Git / Releases , и получение версии или после версии 2.4.5. Исправил это прямо для меня.

Вы, вероятно, клонировали репозиторий в существующем, чтобы решить проблему, можете просто клонировать репозиторий в другом каталоге и скопировать изменения в этот новый каталог, а затем запустить push.

Еще одно дополнение, так как я столкнулся с этой ошибкой по-другому, и Google взял меня сюда.

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

Смотрите: Git: «Мастер не может быть преобразован в ветвь» после слияния

Это может произойти после обновления вашей платформы OSX.

Откройте Терминал и перейдите в свою .ssh-папку и введите ssh-add -K ~/.ssh/id_rsa

PLESK Nginx и GIT Я получал эту ошибку на plesk git, и при отправке большого репозитория с (кто знает, что) он дал мне эту ошибку с HTTP-кодом 413, и я посмотрел, что следующим сервером был Plesk, и на нем был запущен nginx и apache2 так я заглянул в логи и нашел ошибку в логах nginx

Пройдя по этой ссылке, можно разрешить plesk перестроить конфигурацию с большей загрузкой файлов.

Я пропустил часть php для git

После этого git push работал без ошибок.

У меня случилась такая же ошибка при выдергивании.
Я сделал трюк "http.postBuffer". Это решило это, но когда я хотел нажать, я снова столкнулся с ошибкой.

Что решило мою проблему:
1. Клонировал ее в другую папку с другой виртуальной машиной. (Linux).
2. Я сделал свои изменения.
3. Протолкнул его с оригинальной виртуальной машиной, которую я изначально не мог нажать. (Windows)

Я получил эту ошибку, когда у меня была неправильная пара ключей в .ssh. Добавление pubkey к github (в настройках) исправило эту проблему для меня.

У меня та же проблема. На веб-странице git я заметил, что URL клона SSH имеет следующую структуру:

git@github.com:user/project.git

Я мог бы решить мою проблему, просто изменив ":" на "/", следующим образом:

git@github.com/user/project.git

может быть это может быть полезно

Кажется почти бессмысленным добавлять ответ, но я боролся с этим целую вечность, когда я наконец обнаружил, что Visual Studio Online страдает от спорадического сбоя. Это стало очевидным, когда VS продолжал запрашивать кредиты, а веб-сайт VSO иногда давал 500.

Counting objects: 138816, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (38049/38049), done.
error: unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
The remote end hung up unexpectedly/138816), 33.30 MiB | 3.00 KiB/s
Writing objects: 100% (138816/138816), 50.21 MiB | 3.00 KiB/s, done.
Total 138816 (delta 100197), reused 134574 (delta 96515)
fatal: The remote end hung up unexpectedly
Everything up-to-date

После этого я установил свой HTTP-буфер сообщений обратно на 2 Мб, так как на самом деле я думаю, что он лучше работает со многими постами меньшего размера.

Люк

Кажется, это может быть одна из тысячи вещей.

Для меня я изначально подталкивал мастер и развивался (мастер не имел изменений) через SourceTree. Изменение этого для разработки только работало.

Я сталкивался с подобной ошибкой при загрузке большого репозитория, «роковой: удаленный конец неожиданно завис», без каких-либо дополнительных подробностей.

После долгих исследований вот что я сделал:

• Использование SSH вместо HTTPS не решило проблему.
• Увеличивать http.postBuffer постепенно до очень большого значения, все равно не повезло.
• Я выяснил, что это может быть из-за больших файлов в репо (так как это недавно перенесенный репо из перформанса), поэтому я заново создал репо, используя LFS, установив largeFileThreshold на 40 м, что значительно уменьшило размер репо (с 3,5 ГБ до 500M). Я думал, что это решит проблему, но, к моему удивлению, я все еще столкнулся с той же ошибкой.

Наконец, мне пришло в голову, что, возможно, я использую старый git-клиент, так как не вижу дополнительных сообщений об ошибках. Я обновил git client до последней (2.20.1), и вуаля, ошибка исчезла!

Я получил эту ошибку, когда неправильно написал имя моей удаленной ветки

Я смог обойти эту проблему с помощью Git Shell.

Каждый репозиторий на github.com содержит URL-адреса HTTPS / SSH / Subversion, которые можно использовать для загрузки с помощью Shell, см. Здесь: http://prntscr.com/8ydguv .
Основываясь на последних изменениях GitHub, SSH кажется лучшим методом.

Команда для использования в Shell:

git clone "URL of repo goes here w/ no quotes"

Сделайте это, чтобы увидеть ключ, который вы используете; ssh -vT git@github.digitalglobe.com

Затем убедитесь, что в вашей сборке у вас есть этот запуск в начале. eval "$ (ssh-agent -s)" ssh-add ~ / .ssh / id_rsa

1) cd к проекту dir

2) git status

3) git checkout -f HEAD

4) Подтвердите успех, снова потянув мастера, чтобы убедиться, что вы в курсе, если ваш репо выглядел не полностью

Это работает, если вы получаете сообщение об ошибке из Git Visual Studio при клонировании репозитория из Bitbucket

Это также может произойти, если какие-либо коммиты, которые вы нажимаете, искажены.

У меня (по незнанию) был коммит с искаженным полем Email автора, но все, что я получал, это смутное remote end hung upсообщение об ошибке. Я был в состоянии выдвинуть другие отрасли только это не одна ветви, поэтому я начал толкая совершающие от «плохого» филиала одного в то время , пока я , наконец, приземлился в:

Pushing to git@github.com:directangular/unicorn.git
Counting objects: 100% (9/9), done.
Delta compression using up to 20 threads
Writing objects: 100% (5/5), 549 bytes | 549.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: error: object 74c7584ff0b93591c19d3a3c19695889dd2274d2: badEmail: invalid author/committer line - bad email        
remote: fatal: fsck error in packed object        
error: remote unpack failed: index-pack abnormal exit
To github.com:directangular/unicorn.git
 ! [remote rejected]       pizzafeast -> pizzafeast (failed)
error: failed to push some refs to 'git@github.com:directangular/unicorn.git'

Таким образом, похоже, что remote end hung up unexpectedlyошибка является своего рода «проглатыванием» фактического сообщения об ошибке, что, вероятно, является своего рода некорректным коммитом, как у меня здесь.

После исправления искаженного письма я смог толкнуть просто отлично.

Я не думаю, что это хорошая идея, но если у вас есть резервная копия на вашем компьютере ... нажмите еще раз, а затем попробуйте клонировать репозиторий, а затем удалите .git из старого каталога и переместите .git из новой клонированной папки. Git разрешен но из-за этой проблемы некоторые файлы могут не загружаться в git. Снова переместите все назад, затем перетащите его на сервер или другой компьютер, на котором оно прервано. Прямо сейчас я только что сделал ... Работает на меня ... и делаю резервную копию вашего каталога, прежде чем сделать это.

И, пожалуйста, поправьте меня, если я ошибаюсь. Я также не знаю, что может пойти не так после этого? Но на этот раз это действительно работает.

Моя проблема (неустранимая: удаленный конец зависает неожиданно) была решена путем проверки разрешения и владельца хранилища.

Владелец файлов репозитория git должен быть тем пользователем, которому вы хотите push / pull / clone.

Ни один из приведенных выше ответов не сработал для меня, но вот что сработало.

1) удалить .git/из вашего проекта
2) клонировать удаленное хранилище в какое-то новое место, например, на рабочий стол. git clone https://github.com/foo/bar.git
3) переместиться .git/из нового местоположения в старое местоположение
4) повторно зафиксировать и отправить изменения

Причиной проблемы для меня были настройки сети: у меня есть Wi-Fi-карта «Killer», которая, очевидно, работает с сетевыми пакетами так, как не нравятся SSH и SSL.

Чтобы решить проблему, мне пришлось зайти в «Killer Control Center», «Параметры» и отключить «Advanced Stream Detect» - команды git снова начали работать мгновенно.

Эта статья имеет очень хорошее объяснение, и это решило мою проблему.

git config --global http.postBuffer 157286400

https://confluence.atlassian.com/stashkb/git-push-fails-fatal-the-remote-end-hung-up-unexpectedly-282988530.html