fatal: EOF awal fatal: paket-indeks gagal


271

Saya telah mencari di Google dan menemukan banyak solusi tetapi tidak ada yang berhasil untuk saya.

Saya mencoba untuk mengkloning dari satu mesin dengan menghubungkan ke server jauh yang ada di jaringan LAN.
Menjalankan perintah ini dari mesin lain menyebabkan kesalahan.
Tetapi menjalankan perintah kloning SAMA menggunakan git: //192.168.8.5 ... di server tidak apa-apa dan berhasil.

Ada ide?

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

Saya telah menambahkan konfigurasi ini .gitconfigtetapi tidak ada bantuan juga.
Menggunakan versi git 1.8.5.2.msysgit.0

[core]
    compression = -1

8
Saya menghadapi masalah ini selama 2-3 hari ketika saya mencoba untuk mengkloning dari VPN. dalam masalah saya adalah bandwidth jaringan. saya diperbaiki dengan kloning di jaringan kecepatan tinggi.
Avijit Nagare

1
Saya juga memperhatikan itu terkait jaringan.
heran

1
Saya mendapatkan kesalahan ini karena teman-teman saya tidak mengenal git dengan baik dan mendorong banyak gambar ke dalam repositori! =))
Clite Tailor

Saya juga memperhatikan itu terkait jaringan. Saya juga memperbaiki dengan kloning di jaringan kecepatan tinggi.
shashaDenovo

Jawaban:


506

Pertama, matikan kompresi:

git config --global core.compression 0

Selanjutnya, mari kita lakukan tiruan sebagian untuk memotong jumlah info yang turun:

git clone --depth 1 <repo_URI>

Ketika itu berhasil, masuk ke direktori baru dan ambil sisa klon:

git fetch --unshallow 

atau, secara bergantian,

git fetch --depth=2147483647

Sekarang, lakukan tarikan reguler:

git pull --all

Saya pikir ada kesalahan dengan msysgit di versi 1.8.x yang memperburuk gejala ini, jadi pilihan lain adalah mencoba dengan versi git yang lebih lama (<= 1.8.3, saya pikir).


6
Terima kasih, ini berhasil. Saya telah mencoba mengubah http.postbuffer yang tidak berfungsi, tetapi setelah melakukan seperti yang dinyatakan dalam jawaban ini, itu berhasil. Saya tidak menggunakan baris "git fetch --depth = 2147483647", tetapi saya menggunakan sisanya.
Nick Benedict

2
@ EthenA.Wilson Anda harus mengirimkan URL jauh untuk repositori sesudahnya. Misalnya git clone --depth 1 git@host:user/my_project.git.
Nathan Gould

6
@ Jose A. - Saya mengalami masalah ini ketika saya menggunakan versi msysgit yang lebih baru. Jika Anda menggunakan msysgit, coba versi yang lebih lama (<= 1.8.3). Jika tidak, coba git fetch --depth 1000 (lalu 2000, dll., Meningkat secara bertahap sampai semua file ditarik).
ingyhere

2
@ Jose A. - Juga, lihat ini: stackoverflow.com/questions/4826639/…
ingyhere

2
Hai teman baik. Terima kasih atas solusi hebat Anda. Tapi yang terakhir git pull --alltidak berhasil. Karena git clone --depth 1akan menetapkan rentang pengambilan hanya satu cabang. Jadi kita harus mengedit git / config terlebih dahulu.
pjincz

93

Kesalahan ini dapat terjadi untuk kebutuhan memori git. Anda dapat menambahkan baris ini ke file konfigurasi global git Anda, yang ada .gitconfigdi $USER_HOME, untuk memperbaiki masalah itu.

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

Ini bekerja untuk saya - walaupun saya masih membutuhkan beberapa upaya, tetapi tanpa perubahan ini batalkan datang pada 30%, kemudian pada 75% ... dan sekali itu naik menjadi 100% dan berhasil. :)
peschü

Harus jawaban yang dipilih
Asim Qasımzade

Di windows, dengan git 2.19, ini memperbaikinya. Secara khusus menambahkan params terkait paket.
Καrτhικ

Bekerja! Terima kasih!
Guille Acosta

masih belum bekerja untuk saya 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

akhirnya diselesaikan oleh git config --global core.compression 9

Dari utas masalah BitBucket:

Saya mencoba hampir lima kali, dan itu masih terjadi.

Kemudian saya mencoba menggunakan kompresi yang lebih baik dan berhasil!

git config --global core.compression 9

Dari Dokumentasi Git:

core.compression
Integer -1..9, menunjukkan level kompresi standar. -1 adalah default zlib.
0 berarti tidak ada kompresi, dan 1..9 adalah berbagai tradeoff kecepatan / ukuran, 9 paling lambat.
Jika diatur, ini memberikan default ke variabel kompresi lain, seperti core.looseCompression dan pack.compression.


3
Diperlukan untuk berjalan git repackdalam kombinasi dengan solusi ini dan kemudian berhasil.
erikH

Itu berhasil, bahkan tidak mencoba solusi lain karena ini adalah yang terpendek dan paling elegan. harus diterima jawabannya!
metablaster

Ini juga berfungsi untuk saya, melalui VPN dan proksi perusahaan. --compression 0tidak bekerja atau melakukan semua .gitconfigperubahan yang disarankan di atas.
Terrence Brannon

20

Seperti yang dikatakan @ingyhere:

Klon Dangkal

Pertama, matikan kompresi:

git config --global core.compression 0

Selanjutnya, mari kita lakukan tiruan sebagian untuk memotong jumlah info yang turun:

git clone --depth 1 <repo_URI>

Ketika itu berhasil, masuk ke direktori baru dan ambil sisa klon:

git fetch --unshallow

atau, secara bergantian,

git fetch --depth=2147483647

Sekarang, tarik:

git pull --all

Kemudian untuk menyelesaikan masalah master pelacakan cabang Anda saja

buka file git config Anda ( .git/config) di editor pilihan Anda

di mana dikatakan:

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

ubah jalurnya

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

untuk

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

Lakukan git fetch dan git akan menarik semua cabang jarak jauh Anda sekarang


Berhasil, tapi saya meninggalkan kompresi ke 9 bukan 0 yang gagal.
metablaster

9

Dalam kasus saya ini cukup membantu:

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

Ini akan membatasi checkout hanya untuk cabang yang disebutkan, maka akan mempercepat proses.

Semoga ini bisa membantu.


6

Saya mencoba semua perintah itu dan tidak ada yang berhasil untuk saya, tetapi yang berhasil adalah mengubah git_url menjadi http, bukan ssh

jika perintah clone lakukan:

git clone <your_http_or_https_repo_url> 

lain jika Anda menarik repo yang ada, lakukan dengan

git remote set-url origin <your_http_or_https_repo_url>

semoga ini membantu seseorang!


1
Pertanyaan ini sebenarnya tentang pesan kesalahan dalam output di atas ketika ada masalah menyinkronkan potongan file raksasa dari repo yang terhubung. Anda mengatakan bahwa memotong ke https dari ssh memungkinkan klon selesai?
ingyhere

Iya! Itu bekerja untuk saya, saya punya repo + 4gb dan satu-satunya solusi saya mendapat pekerjaan itu adalah itu!
elin3t

2
Ini bekerja untuk saya, terima kasih! Kloning oleh httpsdan kemudian mengatur kembali ke ssh.
Tuan

1
Saya benar-benar ingin tahu mengapa ini berhasil. Apakah ada sesuatu dalam protokol SSH yang tersedak objek besar yang tidak dimiliki HTTPS? Apakah ini masalah lapisan transport?
bdetweiler

6

Saya mendapatkan kesalahan ini ketika git kehabisan memori.

Mengosongkan sebagian memori (dalam hal ini: membiarkan penyelesaian pekerjaan kompilasi) dan mencoba lagi berhasil untuk saya.


Bagi saya, tidak ada banyak memori yang tersedia, membebaskan beberapa dan mencoba lagi menyelesaikannya.
Martin Cassidy

4

Dalam kasus saya itu adalah masalah koneksi. Saya terhubung ke jaringan wifi internal, di mana saya memiliki akses terbatas ke sumber daya. Itu membiarkan git mengambilnya tetapi pada waktu tertentu itu jatuh. Ini berarti masalah koneksi jaringan. Periksa apakah semuanya berjalan dengan baik: Antivirus, Firewall, dll.

Karena itu jawaban elin3t penting karena ssh meningkatkan kinerja pengunduhan sehingga masalah jaringan dapat dihindari


4

Pengaturan konfigurasi di bawah ini tidak berfungsi untuk saya.

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

Seperti komentar sebelumnya, mungkin masalah memori dari git. Jadi, saya mencoba mengurangi thread yang berfungsi (dari 32 menjadi 8). Sehingga tidak akan mendapatkan banyak data dari server secara bersamaan. Lalu saya juga menambahkan "-f" untuk memaksa menyinkronkan proyek lain.

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

Maka itu berfungsi dengan baik sekarang.

repo sync -f -j8

2

Jawaban sebelumnya merekomendasikan pengaturan ke 512m. Saya akan mengatakan ada alasan untuk berpikir itu kontraproduktif pada arsitektur 64bit. The dokumentasi untuk core.packedGitLimit mengatakan:

Standarnya adalah 256 MiB pada platform 32 bit dan 32 TiB (efektif tidak terbatas) pada platform 64 bit. Ini harus masuk akal untuk semua pengguna / sistem operasi, kecuali pada proyek terbesar. Anda mungkin tidak perlu menyesuaikan nilai ini.

Jika Anda ingin mencobanya periksa apakah Anda telah mengaturnya dan kemudian hapus pengaturan:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

1

Perhatikan bahwa Git 2.13.x / 2.14 (Q3 2017) benar-benar meningkatkan standar core.packedGitLimityang memengaruhi git fetch:
Nilai batas paket-git standar telah dinaikkan pada platform yang lebih besar ( dari 8 GiB hingga 32 GiB ) untuk menyelamatkan " git fetch" dari kegagalan (dapat dipulihkan) sementara " gc" berjalan secara paralel.

Lihat komit be4ca29 (20 Apr 2017) oleh David Turner ( csusbdt) .
Dibantu-oleh: Jeff King ( peff) .
(Digabung oleh Junio ​​C Hamano - gitster- dalam komit d97141b , 16 Mei 2017)

Meningkat core.packedGitLimit

Ketika core.packedGitLimitterlampaui, git akan menutup paket.
Jika ada operasi pengemasan ulang yang berjalan paralel dengan pengambilan, pengambilan mungkin membuka paket, dan kemudian dipaksa untuk menutupnya karena packGitLimit dipukul.
Pengemasan ulang kemudian bisa menghapus paket dari bawah pengambilan, menyebabkan pengambilan gagal.

Tambah core.packedGitLimitnilai default untuk mencegah hal ini.

Pada mesin x86_64 64-bit saat ini, 48 bit ruang alamat tersedia.
Tampaknya mesin ARM 64-bit tidak memiliki jumlah ruang alamat standar (yaitu, bervariasi menurut produsen), dan mesin IA64 dan POWER memiliki 64 bit penuh.
Jadi 48 bit adalah satu-satunya batasan yang bisa kita pedulikan. Kami mencadangkan beberapa bit dari ruang alamat 48-bit untuk penggunaan kernel (ini tidak sepenuhnya diperlukan, tetapi lebih baik aman), dan menggunakan hingga 45 sisanya.
Tidak ada repositori git akan berada di dekat sebesar ini kapan saja segera, jadi ini harus mencegah kegagalan.



1

Dalam kasus saya masalahnya bukan parameter konfigurasi git tetapi fakta bahwa repositori saya memiliki satu file melebihi ukuran file maksimum yang diizinkan pada sistem saya. Saya dapat memeriksanya mencoba mengunduh file besar dan mendapatkan "Batas Ukuran File Melebihi" di Debian.

Setelah itu saya mengedit file /etc/security/limits.conf saya dan menambahkannya pada baris berikut: * hard fsize 1000000 * soft fsize 1000000

Untuk benar-benar "menerapkan" nilai batas baru yang Anda butuhkan untuk masuk kembali


1

Terkait secara tangensial dan hanya berguna jika Anda tidak memiliki akses root dan mengekstrak Git secara manual dari RPM (dengan rpm2cpio) atau paket lainnya (.deb, ..) ke dalam subfolder. Kasus penggunaan umum: Anda mencoba menggunakan versi Git yang lebih baru daripada versi lama di server perusahaan.

Jika git klon gagal dengan fatal: index-pack failed tanpa menyebutkan EOF awal tetapi sebagai gantinya pesan bantuan tentang usage: git index-pack, ada versi ketidakcocokan dan Anda perlu menjalankan git dengan --exec-pathparameter:

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

Agar ini terjadi secara otomatis, tentukan di ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

1

Saya memiliki log kesalahan yang sama, menggunakan git (v2.17.1) di ssh. Dalam solusi kasus saya adalah:

  1. Masuk ke repositori git bare server saya.
  2. Panggil git gc.

Lihat dokumentasi git-gc: https://git-scm.com/docs/git-gc .

Misalnya:

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

Sekarang saya dapat mengkloning repositori ini tanpa kesalahan, misalnya di sisi klien:

git clone git@my_server_url.com:my_repo_name

Perintah ini git gcdapat membantu memanggil git client untuk menghindari git pushmasalah yang sama .


Solusi (peretasan) lainnya adalah mengunduh master terakhir tanpa riwayat:

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

Ada kemungkinan buffer overflow tidak akan terjadi.


0

Dalam kasus saya tidak ada yang berfungsi ketika protokolnya adalah https, kemudian saya beralih ke ssh, dan memastikan, saya menarik repo dari komit terakhir dan bukan seluruh riwayat, dan juga cabang tertentu. Ini membantu saya:

git clone --depth 1 "ssh: .git" --branch “specific_branch”


0

Saya mematikan semua unduhan yang saya lakukan sementara itu, yang membebaskan beberapa ruang mungkin dan membersihkan / menurunkan bandwidth



0

Saya memiliki masalah yang sama. Mengikuti langkah pertama di atas saya bisa mengkloning, tetapi saya tidak bisa melakukan hal lain. Tidak dapat mengambil, menarik, atau checkout cabang lama.

Setiap perintah berjalan jauh lebih lambat dari biasanya, lalu mati setelah mengompresi objek.

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

Ini juga terjadi ketika wasit Anda menggunakan terlalu banyak memori. Memangkas memori memperbaikinya untuk saya. Tambahkan saja batas seperti apa yang Anda ambil jadi ->

git fetch --depth=100

Ini akan mengambil file tetapi dengan 100 suntingan terakhir dalam sejarahnya. Setelah ini, Anda dapat melakukan perintah apa saja dengan baik dan dengan kecepatan normal.


apa maksudmu TED?
Vishav Premlall

"jawaban" ini seharusnya merupakan komentar pada jawaban @ingyhere.
mc0e

0

Mencoba sebagian besar jawaban di sini, saya mendapat kesalahan dengan PUTTY SSH Client dengan semua rasi bintang yang mungkin.

Setelah saya beralih ke OpenSSH kesalahan itu hilang (hapus Environment Variable GIT_SSH dan restart git bash).

Saya menggunakan mesin baru dan versi git terbaru. Pada banyak mesin lain / lama (AWS juga) itu berfungsi seperti yang diharapkan dengan PUTTY juga tanpa konfigurasi git.


0

Saya pernah mengalami masalah yang sama. REPO terlalu besar untuk diunduh melalui SSH. Sama seperti yang disarankan @ elin3t, saya telah mengkloning HTTP / HTTPS dan mengubah URL REMOTE di .git / config untuk menggunakan SSH REPO.


0

Saya mendapat masalah yang sama seperti di bawah ini ketika saya menjalankan 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

Kemudian saya memeriksa git status, Ada begitu banyak perubahan yang tidak dikomit. Saya memperbaiki masalah dengan melakukan dan mendorong semua perubahan yang tidak dikomit.


0

Tidak ada solusi di atas yang berfungsi untuk saya.

Solusi yang akhirnya berhasil bagi saya adalah beralih klien SSH. Variabel lingkungan GIT_SSH diatur ke OpenSSH yang disediakan oleh Windows Server 2019. Versi 7.7.2.1

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

Saya cukup memasang dempul, 0,72

choco install putty

Dan mengubah GIT_SSH menjadi

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


0

Saya mencoba hampir semua saran yang dibuat di sini tetapi tidak ada yang berhasil. Bagi kami masalahnya adalah temperamental dan menjadi lebih buruk dan lebih buruk semakin besar repos menjadi (pada Jenkins Windows build slave kami).

Itu akhirnya menjadi versi ssh yang digunakan oleh git. Git dikonfigurasi untuk menggunakan beberapa versi Open SSH, yang ditentukan dalam file .gitconfig pengguna melalui variabel core.sshCommand. Menghapus garis itu memperbaikinya. Saya percaya ini karena Windows sekarang dikirimkan dengan versi SSH yang lebih andal / kompatibel yang digunakan secara default.


-1

Ini bekerja untuk saya, menyiapkan server nama Google karena server nama standar tidak ditentukan, diikuti dengan memulai ulang jaringan:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

-1

Dari klon git, saya mendapatkan:

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

Setelah me-reboot mesin saya, saya bisa mengkloning repo.


Pertama kali, saya tidak percaya Anda hanya me-reboot mesin Anda dapat memperbaiki masalah ini, tetapi saya mencoba semua yang saya dapatkan pesan yang tidak dapat bekerja. jadi saya memutuskan untuk me-reboot mesin saya adalah solusi terakhir saya untuk saya. beruntung bagi saya, ketika mesin mulai saya mencoba untuk mengkloning lagi. Saya tidak bisa mempercayainya. Itu berhasil !!!!!!!
Thxopen



Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.