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

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

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ę).

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

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.

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

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.

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!

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.

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ą

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

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

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.

Korzystając z odpowiedzi @cmpickle, zbudowałem skrypt, aby uprościć proces klonowania.

Znajduje się tutaj: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Możesz uruchomić go za pomocą następującego wiersza:

curl -sL https://git.io/JvtZ5 | sh -s repo_uri repo_folder

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ć

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

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.

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"

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ół

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ć).

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ą.

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.

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.

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.

Ż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

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.

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

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.

Jeśli korzystasz z systemu Windows, możesz chcieć sprawdzić, czy klon git nie powiódł się z powodu niepowodzenia pakietu „index-pack”? .

Zasadniczo po uruchomieniu git.exe daemon ... polecenia wybierz tekst z tego okna konsoli. Ponów próbę ciągnięcia / klonowania, może już działać!

Zobacz tę odpowiedź, aby uzyskać więcej informacji.

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

Żadne z nich nie działało dla mnie, ale załatwienie problemu przy pomocy wbudowanego narzędzia Heroku.

heroku git:clone -a myapp

Dokumentacja tutaj: https://devcenter.heroku.com/articles/git-clone-heroku-app