ölümcül: erken EOF ölümcül: dizin paketi başarısız

Google'ı aradım ve birçok çözüm buldum ancak hiçbiri benim için çalışmıyor.

LAN ağındaki uzak sunucuya bağlanarak bir makineden klonlamaya çalışıyorum.
Bu komutu başka bir makineden çalıştırmak hataya neden olur.
Ancak sunucuda git: //192.168.8.5 ... kullanarak SAME clone komutunu çalıştırmak iyi ve başarılı.

Herhangi bir fikir ?

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

Ben bu yapılandırma ekledim .gitconfigama yardım da yok.
Git 1.8.5.2.msysgit.0 sürümünü kullanma

[core]
    compression = -1

İlk olarak, sıkıştırmayı kapatın:

git config --global core.compression 0

Sonra, aşağı inen bilgi miktarını kısaltmak için kısmi bir klon yapalım:

git clone --depth 1 <repo_URI>

Bu işe yaradığında, yeni dizine gidin ve klonun geri kalanını alın:

git fetch --unshallow 

veya dönüşümlü olarak,

git fetch --depth=2147483647

Şimdi, düzenli bir çekim yapın:

git pull --all

1.8.x sürümlerinde msysgit ile bu belirtileri şiddetlendiren bir aksaklık olduğunu düşünüyorum, bu yüzden başka bir seçenek git'in önceki bir sürümünü denemektir (<= 1.8.3, sanırım).

Bu hata git'in bellek ihtiyaçları için oluşabilir. Bu satırları , sorunu gidermek için .gitconfigiçinde olan global git yapılandırma dosyanıza ekleyebilirsiniz $USER_HOME.

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

sonunda tarafından çözüldü git config --global core.compression 9

Bir BitBucket sorunu iş parçacığından:

Neredeyse beş kez denedim ve hala oluyor.

Sonra daha iyi sıkıştırma kullanmaya çalıştım ve işe yaradı!

git config --global core.compression 9

Git Belgelerinden:

core.compression
Varsayılan sıkıştırma düzeyini belirten -1..9 tamsayısı. -1, zlib varsayılanıdır.
0 sıkıştırma olmadığı anlamına gelir ve 1..9, 9 en yavaş olmak üzere çeşitli hız / boyut dengesidir.
Ayarlanırsa, bu, core.looseCompression ve pack.compression gibi diğer sıkıştırma değişkenlerine varsayılan değer sağlar.

@İngyhere'in dediği gibi:

Sığ Klon

İlk olarak, sıkıştırmayı kapatın:

git config --global core.compression 0

Sonra, aşağı inen bilgi miktarını kısaltmak için kısmi bir klon yapalım:

git clone --depth 1 <repo_URI>

Bu işe yaradığında, yeni dizine gidin ve klonun geri kalanını alın:

git fetch --unshallow

veya dönüşümlü olarak,

git fetch --depth=2147483647

Şimdi bir çekiş yapın:

git pull --all

Sonra yerel şube sadece izleme ustası sorunu çözmek için

git config dosyanızı ( .git/config) istediğiniz düzenleyicide açın

nerede söylüyor:

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

hattı değiştir

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

için

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

Git getirme ve git artık tüm uzak dallarınızı çekecek

Benim durumumda bu oldukça yardımcı oldu:

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

Bu, ödemeyi yalnızca belirtilen şubeyle sınırlandıracak ve böylece süreci hızlandıracaktır.

Umarım bu yardımcı olur.

Tüm bu komutları denedim ve hiçbiri benim için çalışmıyor, ama işe yarayan git_url yerine http yerine ssh

klon komutu ise:

git clone <your_http_or_https_repo_url> 

aksi takdirde mevcut repoyu çekiyorsanız,

git remote set-url origin <your_http_or_https_repo_url>

Umarım bu birine yardım eder!

Git hafızası bittiğinde bu hatayı aldım.

Biraz bellek boşaltmak (bu durumda: derleme işinin bitmesine izin vermek) ve tekrar denemek benim için çalıştı.

Benim durumumda bu bir bağlantı sorunuydu. Ben ressources sınırlı erişim olan bir dahili wifi ağına bağlandı. Git'in getirmeyi yapmasına izin veriyordu ama belli bir zamanda çöktü. Bu, ağ bağlantısı sorunu olabileceği anlamına gelir. Her şeyin düzgün çalışıp çalışmadığını kontrol edin: Antivirüs, Güvenlik Duvarı vb.

Bu nedenle elin3t'nin cevabı önemlidir, çünkü ssh, indirme işleminin performansını iyileştirir, böylece ağ sorunlarından kaçınılabilir

Aşağıdaki yapılandırma ayarı benim için çalışmıyor.

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

Önceki yorum olarak, git'ten bellek sorunu olabilir. Böylece, çalışma dişlerini azaltmaya çalışıyorum (32'den 8'e). Böylece sunucudan aynı anda çok fazla veri almaz. Sonra da diğer projeleri eşitlemeye zorlamak için "-f" ekliyorum.

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

Sonra şimdi iyi çalışıyor.

repo sync -f -j8

Önceki bir yanıt 512 metreye ayarlanmasını önerir. 64bit mimaride bunun verimsiz olduğunu düşünmek için nedenler olduğunu söyleyebilirim. Core.packedGitLimit için dokümantasyon diyor ki:

Varsayılan, 32 bit platformlarda 256 MiB ve 64 bit platformlarda 32 TiB'dir (etkin bir şekilde sınırsız). Bu, en büyük projeler hariç tüm kullanıcılar / işletim sistemleri için makul olmalıdır. Muhtemelen bu değeri ayarlamanız gerekmez.

Denemek istiyorsanız, ayarlayıp ayarlamadığınızı kontrol edin ve ardından ayarı kaldırın:

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

Git 2.13.x / 2.14 (Q3 2017) varsayılan core.packedGitLimitetkiyi yükseltir git fetch:
Varsayılan paketlenmiş git sınır değeri, ( "geri kazanılabilir) bir hatadan " " kurtarmak için daha büyük platformlarda ( 8 GiB'den 32 GiB'ye ) yükseltilmiştir. git fetch" gc" paralel olarak çalışıyor.

Bkz. Taahhüt, be4ca29 (20 Nis 2017), David Turner ( csusbdt) .
Yardım eden: Jeff King ( peff) .
^{(Göre Birleştirilmiş Junio Cı Hamano - gitster- içinde d97141b tamamlama 2017, 16 Mayıs)}

Artırmak core.packedGitLimit

Ne zaman core.packedGitLimitaşıldığında, git paketleri kapanacak.
Bir getirmeye paralel olarak devam eden bir yeniden paketleme işlemi varsa, getirme bir paket açabilir ve paketlenmişGitLimit'in vurulması nedeniyle onu kapatmak zorunda kalabilir.
Yeniden paketleme daha sonra paketi getirme işleminin altından silebilir ve getirme işleminin başarısız olmasına neden olabilir.

core.packedGitLimitBunu önlemek için varsayılan değerini artırın .

Mevcut 64 bit x86_64 makinelerde, 48 bit adres alanı kullanılabilir.
64 bit ARM makinelerinin standart miktarda adres alanı olmadığı (yani üreticiye göre değiştiği) ve IA64 ve POWER makinelerinin tam 64 biti var gibi görünüyor.
Yani 48 bit, makul bir şekilde önemsediğimiz tek sınırdır. Çekirdeğin kullanımı için 48 bit adres alanının birkaç bitini ayırıyoruz (bu kesinlikle gerekli değildir, ancak güvenli olmak daha iyidir) ve kalan 45'e kadar kullanıyoruz.
Hiçbir git deposu bu büyüklüğün yakınında hiçbir zaman olmayacak yakında, bu başarısızlığı önlemek gerekir.

@Cmpickle yanıtını kullanarak, klonlama işlemini basitleştirmek için bir komut dosyası oluşturdum.

Burada barındırılıyor: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Aşağıdaki satırı kullanarak çalıştırabilirsiniz:

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

Benim durumumda sorun git yapılandırma parametrelerinin hiçbiri değildi, ancak depomun sistemimde izin verilen maksimum dosya boyutunu aşan bir dosyaya sahip olması. Ben büyük bir dosya indirmek ve Debian bir "Dosya Boyutu Sınır Aşıldı" elde çalışırken kontrol edebildi.

Bundan sonra /etc/security/limits.conf dosyamı düzenledim ve sonuna aşağıdaki satırları ekledim: * hard fsize 1000000 * soft fsize 1000000

Gerçekte yeniden giriş yapmanız gereken yeni sınır değerleri "uygulamak" için

Teğetsel olarak ilişkili ve yalnızca root erişiminiz yoksa ve Git'i bir RPM'den (rpm2cpio ile) veya başka bir paketten (.deb, ..) bir alt klasöre manuel olarak çıkartmanız durumunda faydalıdır. Tipik kullanım durumu: Git, şirket sunucusundaki eski sürümden daha yeni bir Git sürümünü kullanmaya çalışırsınız.

Git clone ile başarısız olursa fatal: index-pack failed olmadan erken EOF söz ancak bunun yerine yaklaşık bir yardım mesajının usage: git index-pack, orada bir sürüm uyuşmazlığı olduğunu ve birlikte budala çalıştırmak için gereken --exec-pathparametre:

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

Bunun otomatik olarak gerçekleşmesi için şunları belirtin ~/.bashrc:

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

Ben ssh üzerinde git (v2.17.1) kullanarak aynı hata günlükleri vardı. Benim durumumda çözüm:

1. Sunucumun git bare deposuna girin.
2. Arayın git gc.

Git-gc belgelerine bakın: https://git-scm.com/docs/git-gc .

Örneğin:

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

Şimdi bu depoyu hatasız, örneğin istemci tarafında klonlayabiliyorum:

git clone git@my_server_url.com:my_repo_name

Komut git gc, benzer git pushsorunu önlemek için git istemci tarafında çağrılabilir .

Diğer (kesmek) çözümü geçmiş olmadan son ustayı indiriyor:

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

Arabellek taşması olasılığı yoktur.

Benim durumumda, protokol https olduğunda hiçbir şey işe yaramadı, sonra ssh'a geçtim ve temin ettim, repoyu son tarihin değil, tüm tarihin ve belirli bir şubenin çekmesini sağladım. Bu bana yardımcı oldu:

git clone --depth 1 "ssh: .git" --branch “özgül_branch”

Bu arada yaptığım tüm indirmeleri kapattım, bu da muhtemelen biraz yer açtı ve bant genişliğini yukarı / aşağı temizledi

Git-daemon sorunu v2.17.0'da çözülmüş görünüyor (çalışmayan bir v2.16.2.1 ile doğrulandı). Yani konsolda "çıktı arabelleğini kilitlemek" için metin seçmenin geçici bir çözümü gerekmemektedir.

Gönderen https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt :

• "Git daemon" için çeşitli düzeltmeler. (ed15e58efe jk / daemon-fixes'i daha sonra bakım için birleştirin).

Aynı problemim var. Yukarıdaki ilk adımı takiben klonlayabildim, ancak başka bir şey yapamıyorum. Eski şubeler getirilemiyor, çekilemiyor veya ödeme yapılamıyor.

Her komut normalden çok daha yavaş çalışır, ardından nesneleri sıkıştırdıktan sonra ölür.

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

Bu, referanslarınız çok fazla bellek kullandığında da olur. Belleği budamak bunu benim için düzeltti. Sadece getirdiğiniz şeye bir sınır ekleyin ->

git fetch --depth=100

Bu, dosyaları getirecektir, ancak geçmişlerindeki son 100 düzenleme ile. Bundan sonra, herhangi bir komutu gayet iyi ve normal hızda yapabilirsiniz.

Cevapların çoğunu burada denedim , PUTTY SSH İstemcisi ile olası tüm takımyıldızları ile hatayı aldım .

Bir kez ben OpenSSH geçiş hatası (Çevre Değişken GIT_SSH kaldırıp git bash yeniden başlatın) gitmişti.

Yeni bir makine ve en yeni git versiyonlarını kullanıyordum. Diğer birçok / eski makinede (AWS de) PUTTY ile beklendiği gibi çalışmış ve herhangi bir git konfigürasyonu olmadan çalışmıştır.

Aynı sorunu yaşıyorum. REPO, SSH üzerinden indirilemeyecek kadar büyüktü. @ Elin3t tarafından tavsiye edildiği gibi, HTTP / HTTPS üzerinden klonladım ve SSH REPO'yu kullanmak için .git / config içindeki REMOTE URL'sini değiştirdim .

Ben koşarken aşağıdaki aynı sorunu aldım 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

Sonra kontrol ettim, git statusçok fazla taahhütte bulunulmamış değişiklik vardı ve taahhüt edilemeyen değişiklikleri taahhüt ederek sorunu çözdüm.

Yukarıdaki çözümlerin hiçbiri benim için çalışmadı.

Sonunda benim için çalışan çözüm SSH istemcisini değiştirmekti. GIT_SSH ortam değişkeni, Windows Server 2019 tarafından sağlanan OpenSSH olarak ayarlandı. Sürüm 7.7.2.1

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

Basitçe macun taktım, 0.72

choco install putty

Ve GIT_SSH değerini

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

Burada yapılan tüm önerileri hemen hemen denedim ama hiçbiri işe yaramadı. Bizim için sorun mizaçtı ve daha da kötüleşti ve depolar büyüdükçe (Jenkins Windows yapı kölemizde).

Git tarafından kullanılan ssh versiyonu oldu. Git, core.sshCommand değişkeni aracılığıyla kullanıcıların .gitconfig dosyasında belirtilen bazı Açık SSH sürümünü kullanacak şekilde yapılandırıldı. Bu çizgiyi kaldırmak düzeltildi. Bunun, Windows'un artık varsayılan olarak kullanılan SSH'nin daha güvenilir / uyumlu bir sürümüyle birlikte gönderildiğine inanıyorum.

Bu benim için çalıştı, standart ad sunucusu belirtilmediğinden Googles ad sunucusu ayarlandı, ardından ağ yeniden başlatıldı:

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

Git klonundan alıyordum:

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

Makinemi yeniden başlattıktan sonra, repo para cezasını klonlayabildim.

Windows kullanıyorsanız, "index-pack" başarısız olduğunda git clone'un başarısız olup olmadığını kontrol etmek isteyebilirsiniz ? .

Temel olarak, çalıştırdıktan sonra git.exe daemon ... komutunuzu , o konsol penceresinden bir metin seçin. Çekmeyi / klonlamayı tekrar deneyin, şimdi işe yarayabilir!

Daha fazla bilgi için bu cevaba bakınız .

Sürücünüzde yeterli alan kaldığından emin olun

Bunların hiçbiri benim için işe yaramadı, ancak Heroku'nun yerleşik aracını kullanmak hile yaptı.

heroku git:clone -a myapp

Buradaki belgeler: https://devcenter.heroku.com/articles/git-clone-heroku-app