Git zawiesza się podczas pisania obiektów

104

Próbuję git push -u origin masterI po prostu wisi na

Writing objects:  99% (219/220), 12.65 MiB | 97 KiB/s

12.65Część przesuwa się. Kiedy wychodzę z procesu i uruchamiam go ponownie, wznawia się on na 99%, ale nigdy się nie kończy, tak jak wcześniej.

To nigdy nie jest skuteczne. To jest pierwsze zatwierdzenie.

git

— mattalxndr
źródło

Gdzie chcesz popchnąć? Czy używasz SSH lub innego protokołu?

— Paŭlo Ebermann

27

Czy ustawiłbyś http.postbufferpomoc? stackoverflow.com/questions/6842687/…

— VonC,

3

Komentarz VonC jest zbyt łatwy do przeoczenia. Mi to pasuje.

— Czw

1

Nie do wiary. To też zrobiło to dla mnie. A teraz jest 2018 rok. I to jest SSH, a nie HTTP. A całe repozytorium zajmuje około 15 MB. A „zdalnym” serwerem jest localhost. Przestańcie romantyzować Git, ludzie, proszę! ;)

— Sz.

223

Postępowałem zgodnie z radą VonC:

git config --global http.postBuffer 524288000

Dla przyszłych referencji, na podstawie komentarzy:

500 MB: 524288000 (as posted in the original answer)
1 GB: 1048576000
2 GB: 2097152000 (anything higher is rejected as 'out of range')

— Hugo Forte
źródło

4

omg, dziękuję za to! wyrywało mi włosy, a to rozwiązało moje problemy!

— Brett Thomas

3

@HugoForte Zwiększenie bufora wydawało się rozwiązać moje zawieszanie się zapisywania plików, ale mój push git nigdy się nie zakończył (zawiesił się po Writing objects: 100%) - poprzednio zawieszał się na 25%, więc to wyraźnie pomogło. Jednak nadal zachowywałem się „dziwnie”. I ponownie uruchomić mój system , a to wydawało się rzeczy rozstrzygają ... FYI ... jeśli ktoś jest nadal trafienia problemy po zwiększeniu ich bufor, ponowne uruchomienie mój system pomógł w mojej sytuacji (stare rozwiązanie szkoła Niemniej jednak świeży restart naprawdę pomogło).

— twknab

4

Czy ktoś może wyjaśnić, skąd 524288000pochodzi ta liczba ?

— Ryre

7

@Ryre to 500 MB

— Hugo Forte

1

Niech Bóg was błogosławi i

— Stackoverflow

37

Działo się to z powodu ogromnego, niezignorowanego pliku w katalogu repozytorium. Ups.

EDYTOWAĆ

Zawieszenie nastąpiło, ponieważ przesyłanie pliku trwało długo. Plik nie powinien być uwzględniony w wypychaniu.

EDYTOWAĆ

Chociaż prawdą jest, że ogromny plik może być przyczyną tego problemu, jeśli nie możesz zignorować danego pliku lub po prostu musisz go przesłać, postępuj zgodnie z tą odpowiedzią.

— mattalxndr
źródło

@TimoSolo Dlaczego miałbym to zrobić? To ja miałem problem i udokumentowałem dokładną poprawkę. Całkiem proste.

— mattalxndr

4

Tak, twoja poprawka polegała na usunięciu problemu. Ze względu na innych ludzi, którzy faktycznie muszą przesłać duży plik, odpowiedź @ hugo-forte rozwiązuje problem. Nie musisz , po prostu pomyślałem, że pomoże to większej liczbie ludzi - w duchu SO.

— TimoSolo

2

Pytanie nie brzmi: „Jak mogę zatwierdzić, a następnie przesłać ogromny plik?”. Chodzi o to, że „moje pchnięcie dupy nie ma końca. Dlaczego?” Jeśli nie spodziewasz się, że pchnięcie potrwa wieczność, prawdopodobnie (tak jak ja) nie zamierzałeś zatwierdzić tego ogromnego pliku.

— mattalxndr

3

@mattalxndr Gdy zaakceptowana odpowiedź ma 1/8 głosów, prawdopodobnie powinieneś to zmienić.

— NorCalKnockOut

1

@mattalxndr Żadna z odpowiedzi nie jest idealna. Jeden identyfikuje przyczynę, a drugi oferuje rozwiązanie. Idealna odpowiedź powinna zidentyfikować przyczynę, wyjaśnić, dlaczego ma dany skutek i zaproponować dwa alternatywne rozwiązania. IMO, z obecnych opcji, odpowiedź Hugo Forte jest lepsza, ponieważ rozwiąże problem niezależnie od tego, czy zamierzałeś przesłać plik, czy nie. To nie ignorowanie ludzi, którzy popełnili ten sam błąd, co ty; rozwiązuje problem tak samo jak każdy inny, ale pozostawia im usunięcie pliku, jeśli nie zamierzali go przesłać.

— BZ1,

7

Miałem ten sam problem z (pisaniem obiektów% 16) utknięcie, a następnie fatalne. Rozwiązałem to, zapisując bieżące zmiany i klonując nowe repozytorium, a następnie kopiując do niego zmodyfikowane pliki.

Na przykład. Załóżmy, że aktualne repozytorium to A, wtedy wszystko, co musisz zrobić, to:

mv A B
git clone A
mv B/* A/
rm -rf B

Następnie zatwierdzaj i pchaj i wszystko działało dobrze. Rozpoznał przeniesione pliki jako zmodyfikowane :)

— Maha
źródło

Doświadczyłeś innego objawu. Mój nie miał żadnych fatalnych błędów.

— mattalxndr

5

W moim przypadku używałem folderu git ze złymi prawami przechowywanego na tym samym dysku co repozytorium, ale może być tak samo z ssh, nawet jeśli używasz autoryzowanego użytkownika logowania.

Sprawdź wtedy, czy masz odpowiednie uprawnienia do zapisu na odległym repozytorium.

Przykład:

Zainicjuj lokalne i odległe repozytorium

git init /tmp/src
git init --bare /tmp/dst
cd /tmp/src

Dodanie zdalnego repozytorium do pochodzenia

src > git remote add dest /tmp/dst

Symulujący problem

src > chmod -R 555 /tmp/dst

Dodawanie fałszywego pliku i wysyłanie go

src > touch a && git add a && git commit -m 'demo'
src > git push --set-upstream dest master
src > git push
Counting objects: 3, done.
Writing objects: 99% (2/3), 202 bytes | 0 bytes/s.

Git się zawiesza

Rozwiązanie

src > chmod -R 775 /tmp/dst

— Naewis
źródło

2

Prosimy o rozważenie dodania kilku dodatkowych przykładowych szczegółów do swojej odpowiedzi, dzięki.

— Mirza Sisic

1

Przepraszam. Czy lepiej ?

— Naewis,

3

W mojej sytuacji był to rozmiar pliku. Dodając plik .gitignore z wymaganymi rozszerzeniami, mogłem zignorować większość niechcianych plików do wypchnięcia.

— Skitty
źródło

2

W moim przypadku miałem niską prędkość wysyłania do Internetu, a plik, który chciałem wysłać, był duży, sztuka polega na użyciu git LFS (duża pamięć plików), która jest znacznie bardziej cierpliwa przy przesyłaniu dużych plików, możesz znaleźć samouczek git LFS tutaj

— user3160702
źródło

1

git clean -f -nrozwiązuje mój problem. Istnieje wiele nieśledzonych plików, które nie zostały wykryte. Ale bądź ostrożny, ponieważ spowoduje to usunięcie plików w twoim katalogu

— Sherlock
źródło

3

W szczególności, które pliki zostaną usunięte?

— Jazimov

1

W moim przypadku starałem się naciskać, nie wypełniając zasad mojej firmy. Dowiedziałem się później, że powinniśmy rozpocząć nasze komunikaty dotyczące zmian od „MOBIL-XXXX”, gdzie XXXX to numer przypisany programistom w Jira (innym narzędziu używanym do śledzenia procesu rozwoju) przez analityków.

Sprawdź, czy Twoja firma ma podobną regułę ograniczającą.

— Onat Korucu
źródło

0

Miałem ten sam problem na komputerze z systemem Windows 10, writing objectszawieszał się, ale w trochę innej sytuacji.

Problem, który miałem, był tylko wtedy, gdy próbowałem dodać nowe pliki do repozytorium. Jeśli aktualizuję pliki, które już istnieją w repozytorium, wszystko działało dobrze i nie ma znaczenia, czy rozmiar pliku był duży, czy nie. Przede wszystkim próbowałem dodawać nowe skrypty.

Próbowałem każdego innego rozwiązania znalezionego w Internecie, ale w moim przypadku nic nie działało, a ostatnia rzecz, którą próbowałem, faktycznie zadziałała. Wygląda na to, że było to spowodowane niektórymi uprawnieniami systemu Windows dla określonego dysku i folderu, które uniemożliwiają aplikacji zapisywanie w tych określonych folderach lub aktualizowanie plików, nawet gdy jestem zalogowany na koncie administratora i uruchomiłem aplikację jako administrator. Więc to polecenie:

attrib -r +s D:\foldername

naprawił problem dla mnie.

Po prostu zamieszczam to tutaj, może ktoś ma ten sam problem co mój.

— h4rd4r7c0r3
źródło