Как да коригирате грешката „packet_write_wait: Connection to Broken pipe“ в Git

Как мога да поправя проблема, когато git push файлове в моите отдалечени хранилища и извежда грешката „packet_write_wait: Връзка към 13.250.177.223 порт 22: Счупена тръба“? Преди git push бях клонирал проекта от отдалеченото и git add, git commit успешно .

Пробвах git pull, git config http.postBuffer 52428800, но не става.

HP@EverChan MINGW32 /d/ChromeDownload/jiaoben5049/meetingDemo (master)
$ git pull
packet_write_wait: Connection to 52.74.223.119 port 22: Broken pipe
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
HP@EverChan MINGW32 /d/ChromeDownload/jiaoben5049/meetingDemo (master)
$ git config http.postBuffer 52428800
HP@EverChan MINGW32 /d/ChromeDownload/jiaoben5049/meetingDemo (master)
$ git push -u origin master
Counting objects: 46, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (46/46), done.
packet_write_wait: Connection to 13.250.177.223 port 22: Broken pipe
Writing foabjecttals:   8:% The  (4/4remote end hung up u6nex)pectedly
fatal: sha1 file '<stdout>' write error: Broken pipe
fatal: The remote end hung up unexpectedly
HP@EverChan MINGW32 /d/ChromeDownload/jiaoben5049/meetingDemo (master)
$ git push -u origin master
packet_write_wait: Connection to 13.250.177.223 port 22: Broken pipe
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

git github ssh
person EverJust    schedule 09.01.2019    source източник

Отговори (2)


arrow_upward
11
arrow_downward

Това, което работи за мен в контекста на натискането на моето репо в github, беше добавянето на IPQoS=throughput към моя конфигурационен файл в ~/.ssh/config. Другите стъпки, за да се уверите, че SSH е настроен правилно, добавен към вашия акаунт в Github и т.н., са описани подробно тук

person Tanya Gupta    schedule 24.02.2019
comment
Същият проблем с ssh ключове за BitBucket на macOS и IPQoS=throughput беше единственото нещо, което помогна! - person Cel; 21.04.2019

arrow_upward
2
arrow_downward

Уверете се, че вашият SSH URL за вашия отдалечен източник работи:

ssh -T yourServer

Неговият IP адрес не трябва да се променя.

Вижте дали проблемът продължава с най-новия Git за Windows ( PortableGit-2.20.1-64-bit.7z.exe), декомпресирайте в C:\Git и задайте опростен PATH в CMD сесия.

set PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\
set GH=C:\path\to\git
set PATH=%GH%\bin;%GH%\usr\bin;%GH%\mingw64\bin;%PATH%

Забележка: можете да видите съобщения за грешка с packet_write() неуспешно.
Преди дадохме допълнително съобщение за грешка ненужно, което беше коригирано с Git 2.32 (Q2 2021).

Вижте комит 332ec96 (15 април 2021 г.) от Матеус Таварес (matheustavares).
(Обединено от Junio ​​C Hamano -- gitster -- в комит 279a2e6, 30 април 2021 г.)

pkt-line: не докладвайте два пъти грешки при запис на пакети

Подписано от: Матеус Таварес

При write() грешки, packet_write() умира със същото съобщение за грешка, което вече е отпечатано от извиквания, packet_write_gently().
Това създава ненужно многословен и повтарящ се изход:

error: packet write failed 
fatal: packet write failed: <strerror() message>

В допълнение към това, packet_write_gently() не винаги изпълнява очакванията на извикващия, че errno ще бъде правилно зададено преди ненулево връщане.
По-специално, това не е така за грешка при превишаване на максималния размер на пакета с данни.
И така, в този случай packet_write() ще извика die_errno() и ще отпечата strerror(errno) съобщение, което може да е напълно несвързано с действителната грешка.

Коригирайте и двата проблема, като превърнете packet_write() и packet_write_gently() в обвивки на обща функция от по-ниско ниво, която не отпечатва съобщението за грешка, а вместо това го връща в буфер за извикващия към die() или error() според случая.

person VonC    schedule 09.01.2019