fatal: EOF awal fatal: paket-indeks gagal

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

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

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

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.

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

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.

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!

Saya mendapatkan kesalahan ini ketika git kehabisan memori.

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

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

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

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

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.

Menggunakan jawaban @cmpickle, saya membuat skrip untuk menyederhanakan proses klon.

Di-host di sini: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Anda dapat menjalankannya menggunakan baris berikut:

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

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

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

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.

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”

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

Masalah git-daemon tampaknya telah diselesaikan di v2.17.0 (diverifikasi dengan v2.16.2.1 yang tidak berfungsi). Yaitu solusi memilih teks di konsol untuk "mengunci output buffer" seharusnya tidak diperlukan lagi.

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

• Berbagai macam perbaikan untuk "git daemon". (gabungkan ed15e58efe jk / daemon-fixes nanti untuk maint).

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.

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.

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.

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.

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

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.

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

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.

Jika Anda menggunakan Windows, Anda mungkin ingin memeriksa git klon gagal dengan "indeks-paket" gagal? .

Pada dasarnya, setelah menjalankan git.exe daemon ...perintah Anda , pilih beberapa teks dari jendela konsol itu. Coba lagi tarik / kloning, mungkin hanya berfungsi sekarang!

Lihat jawaban ini untuk info lebih lanjut.

Pastikan drive Anda memiliki ruang yang cukup

Tidak ada yang berhasil untuk saya, tetapi menggunakan alat bawaan Heroku berhasil.

heroku git:clone -a myapp

Dokumentasi di sini: https://devcenter.heroku.com/articles/git-clone-heroku-app