fatal: early EOF fatal: index-pack nie powiodło się

271

Poszukałem go i znalazłem wiele rozwiązań, ale żadne z nich nie działa dla mnie.

Próbuję sklonować z jednego komputera, łącząc się ze zdalnym serwerem znajdującym się w sieci LAN.
Uruchomienie tego polecenia z innego komputera powoduje błąd.
Ale uruchomienie komendy SAME clone przy użyciu git: //192.168.8.5 ... na serwerze jest w porządku i udane.

Jakieś pomysły ?

user@USER ~
$ git clone  -v git://192.168.8.5/butterfly025.git
Cloning into 'butterfly025'...
remote: Counting objects: 4846, done.
remote: Compressing objects: 100% (3256/3256), done.
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed

Dodałem tę konfigurację, .gitconfigale nie ma też pomocy.
Korzystanie z wersji git 1.8.5.2.msysgit.0

[core]
    compression = -1
William
źródło
8
Napotkałem ten problem przez 2-3 dni, kiedy próbowałem sklonować z VPN. w moim przypadku problemem była przepustowość sieci. Naprawiłem przez klonowanie w szybkiej sieci.
Avijit Nagare
1
Zauważyłem również, że jest to związane z siecią.
zastanawiam się,
1
Wystąpił ten błąd, ponieważ moi znajomi nie znają dobrze git i wpychają wiele obrazów do repozytorium! =))
Clite Tailor,
Zauważyłem również, że jest to związane z siecią. Naprawiłem także przez klonowanie w szybkiej sieci.
shashaDenovo

Odpowiedzi:

506

Najpierw wyłącz kompresję:

git config --global core.compression 0

Następnie wykonajmy częściowy klon, aby obciąć ilość informacji, które spadają:

git clone --depth 1 <repo_URI>

Gdy to zadziała, przejdź do nowego katalogu i odzyskaj resztę klonu:

git fetch --unshallow 

lub na przemian

git fetch --depth=2147483647

Teraz wykonuj regularne pociągnięcia:

git pull --all

Wydaje mi się, że w wersji 1.8.x występuje usterka związana z msysgit, która zaostrza te objawy, więc inną opcją jest wypróbowanie wcześniejszej wersji git (<= 1.8.3, jak sądzę).

ingyhere
źródło
6
Dziękuję, działało świetnie. Próbowałem zmienić http.postbuffer, który nie działał, ale po zrobieniu tego, jak podano w tej odpowiedzi, działał świetnie. Nie użyłem wiersza „git fetch --depth = 2147483647”, ale użyłem reszty.
Nick Benedict
2
@ EthenA.Wilson Następnie musisz podać zdalny adres URL repozytorium. Np git clone --depth 1 git@host:user/my_project.git.
Nathan Gould
6
@Jose A. - Wystąpił ten problem, gdy korzystałem z nowszej wersji msysgit. Jeśli korzystasz z msysgit, wypróbuj starszą wersję (<= 1.8.3). W przeciwnym razie wypróbuj git fetch --depth 1000 (następnie 2000 itd.), Zwiększając stopniowo, aż wszystkie pliki zostaną ściągnięte).
ingyhere
2
@Jose A. - Zobacz także: stackoverflow.com/questions/4826639/...
ingyhere
2
Cześć, drogi przyjacielu. Dziękuję za twoje świetne rozwiązanie. Ale ostatni git pull --allnie działa. Z uwagi na git clone --depth 1to ustawi zakres pobierania tylko jedną gałąź. Więc najpierw musimy edytować .git / config.
pjincz
93

Ten błąd może wystąpić w związku z potrzebą pamięci git. Możesz dodać te linie do swojego pliku konfiguracyjnego globalnego git, która jest .gitconfigw $USER_HOME, aby rozwiązać ten problem.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m
bhdrkn
źródło
To działało dla mnie - chociaż wciąż potrzebowałem kilku prób, ale bez tej zmiany aborcja przyszła na 30%, potem na 75% ... a kiedy to wzrosło do 100% i zadziałało. :)
peschü
Musi być wybraną odpowiedzią
Asim Qasımzade
Naprawiono to w Windowsie z git 2.19. W szczególności dodanie parametrów związanych z paczką.
Καrτhικ
Pracował! Dzięki!
Guille Acosta
wciąż nie działa dla mnie remote: Enumerating objects: 43, done. remote: Counting objects: 100% (43/43), done. remote: Compressing objects: 100% (24/24), done. error: inflate returned -55/26) fatal: unpack-objects failed
Jeevan Chaitanya
26

w końcu rozwiązany przez git config --global core.compression 9

Z wątku wydania BitBucket:

Próbowałem prawie pięć razy i nadal tak się dzieje.

Potem próbowałem użyć lepszej kompresji i zadziałało!

git config --global core.compression 9

Z dokumentacji Git:

core.compression
Liczba całkowita -1..9, wskazująca domyślny poziom kompresji. -1 to domyślna wartość zlib.
0 oznacza brak kompresji, a 1..9 to różne kompromisy prędkości / wielkości, 9 jest najwolniejsze.
Jeśli jest ustawiony, zapewnia to domyślnie inne zmienne kompresji, takie jak core.looseCompression i pack.compression.

Jacky
źródło
3
Musiał działać git repackw połączeniu z tym rozwiązaniem, a potem zadziałało.
erikH,
To działało, nawet nie próbowałem innych rozwiązań, ponieważ to jest najkrótsze i najbardziej eleganckie. należy przyjąć odpowiedź!
metablaster
Działa to również dla mnie przez VPN i korporacyjny serwer proxy. --compression 0nie działał ani nie wszystkie .gitconfigsugerowane powyżej zmiany.
Terrence Brannon
20

Jak powiedział @ingyhere:

Shallow Clone

Najpierw wyłącz kompresję:

git config --global core.compression 0

Następnie wykonajmy częściowy klon, aby obciąć ilość informacji, które spadają:

git clone --depth 1 <repo_URI>

Gdy to zadziała, przejdź do nowego katalogu i odzyskaj resztę klonu:

git fetch --unshallow

lub na przemian

git fetch --depth=2147483647

Teraz wykonaj ciąg:

git pull --all

Następnie, aby rozwiązać problem lokalnego mistrza śledzenia tylko oddziału

otwórz plik konfiguracyjny git ( .git/config) w wybranym edytorze

gdzie jest napisane:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

zmień linię

fetch = +refs/heads/master:refs/remotes/origin/master

do

fetch = +refs/heads/*:refs/remotes/origin/*

Wykonaj pobieranie git, a git pociągnie teraz wszystkie twoje zdalne gałęzie

cmpickle
źródło
Działa, ale zostawiłem kompresję na 9, a nie 0, co nie powiodło się.
metablaster
9

W moim przypadku było to bardzo pomocne:

git clone --depth 1 --branch $BRANCH $URL

Ograniczy to kasy tylko do wspomnianej gałęzi, a tym samym przyspieszy proces.

Mam nadzieję, że to pomoże.

sMajeed
źródło
6

Próbowałem wszystkich tych poleceń i żadne nie działa dla mnie, ale to, co zadziałało, zmieniło git_url na http zamiast ssh

Jeśli polecenie klonowania to:

git clone <your_http_or_https_repo_url> 

w przeciwnym razie, jeśli korzystasz z istniejącego repozytorium, zrób to z

git remote set-url origin <your_http_or_https_repo_url>

mam nadzieję, że to komuś pomoże!

elin3t
źródło
1
To pytanie naprawdę dotyczy komunikatu o błędzie na powyższym wyjściu, gdy występuje problem z synchronizacją dużych fragmentów plików z podłączonego repozytorium. Mówisz, że przejście do https z ssh pozwoliło klonowi się skończyć?
ingyhere
Tak! Ta praca dla mnie, mam repozytorium 4 GB + i jedynym rozwiązaniem, jakie dostałem, była ta praca!
elin3t
2
Działa dla mnie, dziękuję! Sklonuj przez, httpsa następnie ustaw zdalny z powrotem na ssh.
Tuan
1
Naprawdę chciałbym wiedzieć, dlaczego to zadziałało. Czy w protokole SSH jest coś, co dusi duże obiekty, czego nie robi HTTPS? Czy to problem z warstwą transportową?
bdetweiler,
6

Wystąpił ten błąd, gdy w git zabrakło pamięci.

Zwolnienie pamięci (w tym przypadku: zakończenie pracy kompilacji) i ponawianie próby zadziałało dla mnie.

André Laszlo
źródło
Dla mnie nie było dużo pamięci, uwolnienie jej i ponawianie prób rozwiązało.
Martin Cassidy
4

W moim przypadku był to problem z połączeniem. Byłem podłączony do wewnętrznej sieci Wi-Fi, w której miałem ograniczony dostęp do zasobów. To pozwoliło gitowi pobrać, ale w pewnym momencie się zawiesił. Oznacza to, że może to być problem z połączeniem sieciowym. Sprawdź, czy wszystko działa poprawnie: antywirus, zapora sieciowa itp.

Odpowiedź elin3t jest zatem ważna, ponieważ ssh poprawia wydajność pobierania, dzięki czemu można uniknąć problemów z siecią

iberbeu
źródło
4

Ustawienie poniższej konfiguracji nie działa dla mnie.

[core] 
packedGitLimit = 512m 
packedGitWindowSize = 512m 
[pack] 
deltaCacheSize = 2047m 
packSizeLimit = 2047m 
windowMemory = 2047m

Jak poprzedni komentarz, może to być problem z pamięcią git. Dlatego staram się zmniejszyć działające wątki (z 32 do 8). Aby nie pobierało dużo danych z serwera w tym samym czasie. Następnie dodaję też „-f”, aby wymusić synchronizację innych projektów.

-f: Proceed with syncing other projects even if a project fails to sync.

Więc teraz działa dobrze.

repo sync -f -j8
KimmyYang
źródło
2

Poprzednia odpowiedź zaleca ustawienie 512m. Powiedziałbym, że istnieją powody, by sądzić, że przy architektury 64-bitowej przynosi to efekt przeciwny do zamierzonego. Dokumentacja core.packedGitLimit mówi:

Domyślnie 256 MiB na platformach 32-bitowych i 32 TiB (efektywnie nieograniczony) na platformach 64-bitowych. Powinno to być uzasadnione dla wszystkich użytkowników / systemów operacyjnych, z wyjątkiem największych projektów. Prawdopodobnie nie trzeba dostosowywać tej wartości.

Jeśli chcesz go wypróbować, sprawdź, czy go masz, a następnie usuń ustawienie:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit
8DH
źródło
1

Zauważ, że Git 2.13.x / 2.14 (III kwartał 2017) podnosi wartość domyślną, core.packedGitLimitco ma wpływ git fetch:
Domyślna wartość graniczna upakowanego git została podniesiona na większych platformach ( z 8 GiB do 32 GiB ), aby uchronić się git fetchprzed awarią (możliwą do odzyskania) podczas gdy „ gc” działa równolegle.

Zobacz commit be4ca29 (20 kwietnia 2017 r.) Autor: David Turner ( csusbdt) .
Pomoc: Jeff King ( peff) .
(Połączone przez Junio ​​C. Hamano - gitster- w commit d97141b , 16 maja 2017 r.)

Zwiększać core.packedGitLimit

Kiedy core.packedGitLimitzostanie przekroczony, git zamknie paczki.
Jeśli równolegle z pobieraniem trwa operacja przepakowania, pobieranie może otworzyć paczkę, a następnie zostać zmuszonym do jej zamknięcia z powodu trafienia spakowanegoGitLimit.
Przepakowanie może następnie usunąć pakiet spod pobierania, powodując niepowodzenie pobierania.

Zwiększ core.packedGitLimitwartość domyślną, aby temu zapobiec.

Na obecnych 64-bitowych komputerach x86_64 dostępnych jest 48 bitów przestrzeni adresowej.
Wygląda na to, że 64-bitowe maszyny ARM nie mają standardowej ilości przestrzeni adresowej (to zależy od producenta), a maszyny IA64 i POWER mają pełne 64 bity.
Zatem 48 bitów to jedyny limit, na którym możemy racjonalnie dbać. Zarezerwowaliśmy kilka bitów 48-bitowej przestrzeni adresowej na użytek jądra (nie jest to absolutnie konieczne, ale lepiej być bezpiecznym) i wykorzystujemy do pozostałych 45.
Żadne repozytorium git nie będzie w pobliżu tak dużego miejsca wkrótce, więc powinno to zapobiec awarii.

VonC
źródło
1

W moim przypadku problemem nie był żaden parametr konfiguracyjny git, ale fakt, że moje repozytorium miało jeden plik przekraczający maksymalny dozwolony rozmiar pliku w moim systemie. Byłem w stanie to sprawdzić, próbując pobrać duży plik i uzyskać „Przekroczony limit rozmiaru pliku” na Debianie.

Następnie edytowałem mój plik /etc/security/limits.conf, dodając i na końcu następujące wiersze: * hard fsize 1000000 * soft fsize 1000000

Aby faktycznie „zastosować” nowe wartości graniczne, musisz się ponownie zalogować

tpalanques
źródło
1

Stycznie powiązane i przydatne tylko w przypadku, gdy nie masz dostępu do roota i ręcznie wyodrębnij Git z RPM (z rpm2cpio) lub innego pakietu (.deb, ..) do podfolderu. Typowy przypadek użycia: próbujesz użyć nowszej wersji Git zamiast przestarzałej na serwerze korporacyjnym.

Jeśli klon git nie powiedzie się fatal: index-pack failed bez wcześniejszej wzmianki o EOF, ale zamiast tego pojawi się komunikat o pomocy usage: git index-pack, występuje niezgodność wersji i musisz uruchomić git z --exec-pathparametrem:

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

Aby stało się to automatycznie, określ w ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec
Tyblitz
źródło
1

Miałem te same dzienniki błędów, używając git (v2.17.1) nad ssh. W moim przypadku rozwiązaniem jest:

  1. Wejdź do repozytorium git bare mojego serwera.
  2. Zadzwoń git gc.

Zobacz dokumentację git-gc: https://git-scm.com/docs/git-gc .

Na przykład:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc

Teraz mogę sklonować to repozytorium bez błędów, np. Po stronie klienta:

git clone git@my_server_url.com:my_repo_name

Polecenie git gcmoże pomóc wywoływane po stronie klienta git, aby uniknąć podobnego git pushproblemu.


Innym rozwiązaniem (hack) jest pobieranie ostatniego wzorca bez historii:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

Istnieje prawdopodobieństwo, że przepełnienie bufora nie nastąpi.

Michał Jaroń
źródło
0

W moim przypadku nic nie działało, gdy protokołem był https, potem przełączyłem się na ssh i upewniłem się, że wyciągnąłem repo z ostatniego zatwierdzenia, a nie całej historii, a także konkretnej gałęzi. Pomogło mi to:

git clone --depth 1 "ssh: .git" --branch „specific_branch"

Shripada
źródło
0

W międzyczasie wyłączyłem wszystkie pobierane pliki, co prawdopodobnie zwolniło trochę miejsca i wyczyściło przepustowość w górę / w dół

Bartłomiej Wach
źródło
0

Wydaje się, że problem git-demona został rozwiązany w wersji v2.17.0 (zweryfikowany z niedziałającym v2.16.2.1). Oznacza to, że obejście wyboru tekstu w konsoli w celu „zablokowania bufora wyjściowego” nie powinno być dłużej wymagane.

Od https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt :

  • Różne poprawki do „git daemon”. (Scal ed15e58efe jk / daemon-fixes później, aby zachować).
GreenMoose
źródło
0

Mam ten sam problem. Po wykonaniu pierwszego kroku udało mi się sklonować, ale nie mogę zrobić nic więcej. Nie można pobierać, wyciągać ani kasować starych gałęzi.

Każde polecenie działa znacznie wolniej niż zwykle, a następnie umiera po skompresowaniu obiektów.

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

Dzieje się tak również wtedy, gdy twoi sędziowie używają zbyt dużo pamięci. Przycinanie pamięci naprawiło to dla mnie. Po prostu dodaj limit tego, co pobierasz, więc ->

git fetch --depth=100

Spowoduje to pobranie plików, ale z ich ostatnimi 100 edycjami w ich historii. Następnie możesz wykonać dowolne polecenie z normalną szybkością.

Vishav Premlall
źródło
co masz na myśli TED?
Vishav Premlall
ta „odpowiedź” powinna być komentarzem do odpowiedzi @ingyhere.
mc0e
0

Wypróbowałem większość odpowiedzi tutaj, otrzymałem błąd z klientem PUTTY SSH ze wszystkimi możliwymi konstelacjami.

Po przejściu na OpenSSH błąd zniknął (usuń zmienną środowiskową GIT_SSH i zrestartuj git bash).

Używałem nowej maszyny i najnowszych wersji git. Na wielu innych / starszych maszynach (również AWS) działało to zgodnie z oczekiwaniami również z PUTTY bez żadnej konfiguracji git.

Max
źródło
0

Mam ten sam problem. REPO było zbyt duże, aby można je było pobrać przez SSH. Tak jak zalecane @ elin3t, sklonowałem przez HTTP / HTTPS i zmieniłem ZDALNY URL w .git / config, aby używać SSH REPO.

Rodel
źródło
0

Po uruchomieniu mam ten sam problem, co poniżej git pull

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Potem sprawdziłem: git statusByło tak wiele niezaangażowanych zmian, że naprawiłem problem, zatwierdzając i wypychając wszystkie niezaangażowane zmiany.

Kiran Reddy
źródło
0

Żadne z powyższych rozwiązań nie działało dla mnie.

Rozwiązaniem, które w końcu działało dla mnie, było przełączenie klienta SSH. Zmienna środowiskowa GIT_SSH została ustawiona na OpenSSH dostarczoną przez Windows Server 2019. Wersja 7.7.2.1

C:\Windows\System32\OpenSSH\ssh.exe

Po prostu zainstalowałem kit 0,72

choco install putty

I zmieniłem GIT_SSH na

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE

careri
źródło
0

Próbowałem prawie wszystkich podanych tu sugestii, ale żadna nie działała. Dla nas problem był temperamentalny i stawał się coraz gorszy wraz ze wzrostem liczby repozytoriów (w naszym niewolniczym kompilatorze Windows Jenkinsa).

Ostatecznie jest to wersja ssh używana przez git. Git został skonfigurowany do korzystania z niektórych wersji Open SSH, określonych w pliku .gitconfig użytkowników za pomocą zmiennej core.sshCommand. Usunięcie tej linii naprawiło to. Wierzę, że dzieje się tak, ponieważ system Windows jest teraz wyposażony w bardziej niezawodną / kompatybilną wersję SSH, która jest domyślnie używana.

aatwo
źródło
-1

Działa to dla mnie, konfigurowanie serwera nazw Googles, ponieważ nie określono standardowego serwera nazw, a następnie restartowanie sieci:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0
Luca Steeb
źródło
-1

Z klona Git otrzymywałem:

error: inflate: data stream error (unknown compression method)
fatal: serious inflate inconsistency
fatal: index-pack failed

Po ponownym uruchomieniu komputera mogłem dobrze sklonować repo.

Paul Sturgess
źródło
Za pierwszym razem nie mogę uwierzyć, że ponowne uruchomienie komputera może rozwiązać ten problem, ale wypróbowałem wszystkie dostępne wiadomości, które nie mogą działać. więc postanowiłem zrestartować komputer, co jest moim ostatnim rozwiązaniem. na szczęście dla mnie, kiedy maszyna się uruchamia, próbuję sklonować ponownie. Nie mogę w to uwierzyć. To działa !!!!!!!
Thxopen
-2

Upewnij się, że na dysku jest wystarczająco dużo miejsca

Rozwiązania IndieTech
źródło