Git, fatal: Odległy koniec nieoczekiwanie się rozłączył

Kiedy próbowałem biec

git push origin master --force

Właśnie dostałem

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

Czy to ma coś wspólnego z brakiem bezpieczeństwa? Próbowałem utworzyć klucz publiczny, jak w odpowiedzi na Fatal: Zdalny koniec nieoczekiwanie rozłączył się i uruchomił go ponownie, ale nadal nie działa. Czy tak naprawdę nie używam klucza? Jeśli tak, jak z niego korzystać?

Wygląda to podobnie do tego, jak mogę ustawić github jako domyślny na ssh, a nie https dla nowych repozytoriów . Prawdopodobnie warto spróbować przełączyć się z protokołu HTTP na ssh:

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

Problem wynika z ustawień bufora git / https. Aby go rozwiązać (wzięte z Gita nie udaje się, gdy wypychasz zatwierdzenie do github )

git config http.postBuffer 524288000

I ponownie uruchom komendę

Przyczyna: Przekroczono domyślny rozmiar pliku dla Git.

Rozwiązanie :

Przejdź do repozytorium.

Uruchom następującą komendę, aby zwiększyć bufor do 500 MB po przejściu do repozytorium:

git config http.postBuffer 524288000

Może pojawić się taki błąd

błąd: nie można zablokować pliku konfiguracyjnego .git / config: Brak takiego pliku lub katalogu

to dlatego, że nie masz lokalnego .git/configpliku Możesz uruchomić go za pomocą tego polecenia

git config --global http.postBuffer 524288000

Inne rozwiązania nie działały w moim przypadku, naprawienie śmiecia naprawiło to dla mnie:

git gc --aggressive

W przeciwieństwie do jednej z pozostałych odpowiedzi - miałem problem z wypychaniem za pomocą ssh - przełączyłem się na https i zostało to naprawione.

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

Ten błąd można również zgłosić przez brak uprawnień do zapisu w repozytorium.

Moja konkretna sprawa wyglądała następująco:

1. Utworzyłem repozytorium z rootużytkownikiem mojego serwera (przez SSH).
2. Zainstalowałem usługę git i utworzyłem gitużytkownika linux, który powinien zarządzać wszystkimi działaniami związanymi z git.
3. Do tego czasu zapomniałem, że repozytorium zostało utworzone z rootużytkownikiem, a gitużytkownik po prostu nie miał uprawnień do zapisywania czegokolwiek w repozytorium.

Culprit (w moim przypadku):
sieć o dużym opóźnieniu.

Nie jest to odpowiedź sama w sobie, ale raczej spostrzeżenie, które może pomóc innym. Odkryłem, że ten błąd pojawia się czasami w sieciach o dużych opóźnieniach (muszę na przykład użyć anteny satelitarnej do dostępu do Internetu). Szybkość sieci jest dobra, ale opóźnienia mogą być wysokie. Uwaga: problem występuje tylko w niektórych scenariuszach, ale nie ustaliłem, jaki jest wzorzec.

Tymczasowe ograniczenie:
zmieniłem sieci - przeniosłem się do wolniejszej, ale o mniejszych opóźnieniach sieci komórkowej (mój telefon był używany jako hotspot) - i problem zniknął. Pamiętaj, że mogę to robić tylko w sposób przerywany, ponieważ moja łączność z komórkami jest również przerywana. Ponadto wykorzystanie przepustowości zwiększa koszty. Mam również szczęście, że mam tę opcję dostępną. Nie wszyscy to robią.

Jestem pewien, że jest gdzieś jakieś ustawienie konfiguracji, które sprawia, że ​​git - albo ssh, curl albo cokolwiek pierwszy raz - jest bardziej tolerancyjny dla takich sieci, ale nie wiem co to jest.

Apel do deweloperów:
Tego rodzaju problemy stanowią stały problem dla ludności wiejskiej. Pomyśl o nas podczas projektowania systemów, narzędzi i aplikacji. Dziękuję Ci.

W naszym przypadku problemem był klon, który napisał .git/configplik zawierający wpis adresu URL będący metodą dostępu tylko do odczytu. Zmiana adresu URL z ://metody na @metodę naprawiła problem.

Bieganie git remote -vrozjaśniło problem.

Jeśli używasz git dla systemu Windows (i prawdopodobnie tak jest, jeśli robisz to na komputerze z systemem Windows) i żadna z innych poprawek tutaj nie działała, spróbuj przejść na stronę https://github.com/git-for- windows / git / releases i pobieranie wersji w wersji 2.4.5 lub późniejszej Naprawiłem to dla mnie.

Prawdopodobnie sklonowałeś repozytorium w ramach istniejącego, aby rozwiązać problem, możesz po prostu sklonować repozytorium w innym katalogu i zreplikować zmiany w tym nowym katalogu, a następnie uruchomić wypychanie.

Kolejny dodatek, ponieważ napotkałem ten błąd w inny sposób i Google mnie tu zabrał.

Moim problemem było niedopasowanie sprawy; jeden camelCase i jeden nie. Najwyraźniej GIT przestaje to robić, nie mówiąc ci, dlaczego. Więc jeśli twoje gałęzie różnią się od zdalnego tylko wielkimi literami, spróbuj zmienić je tak, aby były identyczne.

Zobacz: Git: „Master nie może zostać rozgałęziony” po scaleniu

Może się to zdarzyć po zaktualizowaniu platformy OSX.

Otwórz Terminal i przejdź do folderu .ssh i naciśnij klawisz Enter ssh-add -K ~/.ssh/id_rsa

PLESK Nginx i GIT Otrzymywałem ten błąd na plesk git i podczas wypychania dużego repozytorium za pomocą (kto wie co) dało mi ten błąd z kodem HTTP 413 i spojrzałem na następujący serwer to Plesk i miał działający nginx oraz apache2 więc przejrzałem dzienniki i znalazłem błąd w dziennikach nginx

Podążałem za tym linkiem, aby umożliwić plesk przebudować konfigurację przy większym przesyłaniu plików.

Pominąłem część php dla git

Po tym git push działał bez żadnych błędów.

Zdarzyło mi się mieć ten sam błąd podczas ściągania.
Zrobiłem sztuczkę „http.postBuffer”. To rozwiązało, ale kiedy chciałem pchać, ponownie napotkałem błąd.

Co rozwiązało mój problem:
1. Sklonowałem go do innego folderu z inną maszyną wirtualną. (Linux).
2. Wprowadziłem zmiany.
3. Wepchnąłem ją z oryginalną maszyną wirtualną, której początkowo nie mogłem pchać. (Windows)

Wystąpił ten błąd, gdy miałem niepoprawną parę kluczy w .ssh. Dodanie klucza pub do github (w ustawieniach) naprawiło ten problem.

Mam ten sam problem. Zauważyłem ze strony internetowej git, że URL sklonowanego SSH ma następną strukturę:

git@github.com:user/project.git

Mógłbym rozwiązać problem, zmieniając „:” przez „/” w następujący sposób:

git@github.com/user/project.git

może to być pomocne.

Wydaje się niemal bezcelowe dodawanie odpowiedzi, ale walczyłem z nią przez wieki, kiedy w końcu odkryłem, że to Visual Studio Online cierpi na sporadyczne awarie. Stało się to oczywiste, gdy VS wciąż prosił o kredyty, a strona VSO czasami dawała 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

Następnie ustawiłem bufor bufora postów HTTP z powrotem na 2 MB, ponieważ myślę, że lepiej działa z wieloma mniejszymi postami.

Łukasz

Wygląda na to, że może to być jedna z tysiąca rzeczy.

Dla mnie początkowo pchałem master i rozwijałem się (master nie miał żadnych zmian) przez SourceTree. Zmiana tego, aby rozwijać, działała tylko.

Miałem podobny błąd podczas przesyłania dużego repozytorium, „fatal: Remote end nieoczekiwanie się rozłączył” bez dalszych szczegółów.

Po wielu badaniach, oto co zrobiłem:

• Używanie SSH zamiast HTTPS nie rozwiązało problemu.
• Zwiększanie http.postBuffer stopniowo do bardzo dużej wartości, wciąż nie ma szczęścia.
• Doszedłem do wniosku, że może to być spowodowane dużymi plikami w repozytorium (ponieważ jest to nowo migrowane repozytorium z perforce), więc odtworzyłem repozytorium za pomocą LFS, ustawiając largeFileThreshold na 40 m, co znacznie zmniejszyło rozmiar repo (z 3,5G do 500 mln). Myślałem, że to rozwiąże problem, ale ku mojemu zaskoczeniu wciąż napotykałem ten sam błąd.

Wreszcie przyszło mi do głowy, że mogę używać starszego klienta git, ponieważ nie widziałem dodatkowych komunikatów o błędach. I uaktualniony do najnowszej git klienta (2.20.1) i voila, błąd zniknął!

Wystąpił ten błąd, gdy źle napisałem nazwę mojego zdalnego oddziału

Udało mi się obejść ten problem za pomocą Git Shell.

Każde repozytorium w witrynie github.com zawiera adresy URL HTTPS / SSH / Subversion, których można użyć do pobrania za pomocą powłoki, patrz tutaj: http://prntscr.com/8ydguv .
Na podstawie ostatnich zmian GitHub, SSH wydaje się być najlepszą metodą.

Polecenie do użycia w powłoce:

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

Zrób to, aby zobaczyć klucz, którego używasz; ssh -vT git@github.digitalglobe.com

Następnie upewnij się, że w swojej wersji masz to uruchomienie na początku. eval "$ (ssh-agent -s)" ssh-add ~ / .ssh / id_rsa

1) cd do projektu reż

2) git status

3) git checkout -f HEAD

4) potwierdź sukces, ponownie pociągając suwak w dół, aby upewnić się, że jesteś na bieżąco, jeśli Twoje repo wyglądało na niepełne

Działa to, jeśli pojawi się błąd z Git Visual Studio podczas klonowania repozytorium z Bitbucket

Może się to również zdarzyć, jeśli któryś z zatwierdzanych przez Ciebie zmian jest zniekształcony.

Miałem (nieświadomie) zatwierdzenie ze zniekształconym polem adresu e-mail autora, ale otrzymywałem tylko ten niejasny remote end hung upkomunikat o błędzie. Udało mi się wcisnąć inne oddziały nie tylko ten jeden oddział, więc zacząłem popychając zobowiązuje od „złego” jednej gałęzi na raz aż w końcu wylądował na:

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'

Wygląda więc na to, że remote end hung up unexpectedlybłąd polega na „przełykaniu” rzeczywistego komunikatu o błędzie, który jest prawdopodobnie rodzajem zniekształconego zatwierdzenia, jak tutaj.

Po naprawieniu źle sformułowanego adresu e-mail udało mi się dobrze wypchnąć.

Nie sądzę, że to dobry pomysł, aby to zrobić, ale jeśli masz kopię zapasową na swoim komputerze ... naciśnij jeszcze raz, a następnie spróbuj klonować repo, a następnie usuń .git ze starego katalogu i przenieś .git z nowego sklonowanego folderu .. git został rozwiązany ale z powodu problemu niektóre pliki mogą nie zostać przesłane na git. Wciśnij ponownie wszystko od ur z powrotem, a następnie przeciągnij go na serwer ur lub inny komputer, na którym jest uszkodzony. W tej chwili właśnie to zrobiłem ... Działa dla mnie .. i zrób kopię zapasową swojego katalogu, zanim to zrobisz.

I proszę mnie poprawić, jeśli się mylę. Nie wiem też, co może pójść źle po wykonaniu tej czynności? Ale tym razem to naprawdę działa.

mój problem (krytyczny: zdalne zakończenie zostało nieoczekiwanie zawieszone) został rozwiązany przez sprawdzenie uprawnień i właściciela repozytorium.

Właścicielem plików repozytorium git musi być ten użytkownik, którego chcesz użyć do push / pull / clone.

Żadna z powyższych odpowiedzi nie działała dla mnie, ale oto, co zadziałało.

1) usuń .git/z projektu
2) sklonuj zdalne repozytorium w nowej lokalizacji, takiej jak pulpit. git clone https://github.com/foo/bar.git
3) przenieś .git/z nowej lokalizacji do starej lokalizacji
4) ponów zatwierdzenie i pchnij zmiany

Problemem były dla mnie ustawienia sieciowe: mam kartę Wi-Fi „Killer”, która najwyraźniej psuje się z pakietami sieciowymi w sposób, którego nie lubią SSH i SSL.

Aby rozwiązać problem, musiałem wejść do „Killer Control Center”, „Parameters” i wyłączyć „Advanced Stream Detect” - polecenia git znów zaczęły działać natychmiast.

Ten artykuł ma bardzo dobre wyjaśnienie i rozwiązał mój problem.

git config --global http.postBuffer 157286400

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