fatale: inizio EOF fatale: pacchetto di indici fallito

Ho cercato su Google e ho trovato molte soluzioni, ma nessuna funziona per me.

Sto cercando di clonare da una macchina collegandomi al server remoto che si trova nella rete LAN.
L'esecuzione di questo comando da un'altra macchina causa errori.
Ma eseguire il comando clone SAME usando git: //192.168.8.5 ... sul server va bene e ha successo.

Qualche idea ?

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

Ho aggiunto questa configurazione .gitconfigma nessun aiuto anche.
Usando la versione 1.8.5.2.msysgit.0 di git

[core]
    compression = -1

Innanzitutto, disattiva la compressione:

git config --global core.compression 0

Quindi, facciamo un clone parziale per troncare la quantità di informazioni che scendono:

git clone --depth 1 <repo_URI>

Quando funziona, vai nella nuova directory e recupera il resto del clone:

git fetch --unshallow 

o, alternativamente,

git fetch --depth=2147483647

Ora fai un tiro regolare:

git pull --all

Penso che ci sia un problema con msysgit nelle versioni 1.8.x che aggrava questi sintomi, quindi un'altra opzione è provare con una versione precedente di git (<= 1.8.3, credo).

Questo errore può verificarsi per esigenze di memoria di git. È possibile aggiungere queste righe al file di configurazione globale di git, che è .gitconfigin $USER_HOME, al fine di risolvere il problema.

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

finalmente risolto da git config --global core.compression 9

Da un thread di emissione BitBucket:

Ci ho provato quasi cinque volte, e succede ancora.

Quindi ho provato a usare una compressione migliore e ha funzionato!

git config --global core.compression 9

Dalla documentazione Git:

core.compression
Un numero intero -1..9, che indica un livello di compressione predefinito. -1 è il valore predefinito di zlib.
0 significa nessuna compressione e 1..9 sono vari compromessi di velocità / dimensione, 9 è il più lento.
Se impostato, questo fornisce un valore predefinito ad altre variabili di compressione, come core.looseCompression e pack.compression.

Come diceva @ingyhere:

Clone Poco Profondo

Innanzitutto, disattiva la compressione:

git config --global core.compression 0

Quindi, facciamo un clone parziale per troncare la quantità di informazioni che scendono:

git clone --depth 1 <repo_URI>

Quando funziona, vai nella nuova directory e recupera il resto del clone:

git fetch --unshallow

o, alternativamente,

git fetch --depth=2147483647

Ora fai un tiro:

git pull --all

Quindi, per risolvere il problema del master di tracciamento solo della filiale locale

apri il tuo file git config ( .git/config) nell'editor di tua scelta

dove dice:

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

cambia la linea

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

per

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

Fai un recupero git e git tirerà tutti i tuoi rami remoti ora

Nel mio caso questo è stato abbastanza utile:

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

Ciò limiterà il checkout solo al ramo menzionato, quindi accelererà il processo.

Spero che questo possa aiutare.

Ho provato tutti questi comandi e nessuno funziona per me, ma ciò che ha funzionato è stato cambiare git_url in http invece di ssh

se è il comando clone fare:

git clone <your_http_or_https_repo_url> 

altrimenti se stai eseguendo il repository esistente, fallo con

git remote set-url origin <your_http_or_https_repo_url>

spero che questo aiuti qualcuno!

Ho avuto questo errore quando git ha esaurito la memoria.

Liberare un po 'di memoria (in questo caso: terminare un processo di compilazione) e riprovare ha funzionato per me.

Nel mio caso è stato un problema di connessione. Ero collegato a una rete wifi interna, in cui avevo un accesso limitato alle risorse. Ciò stava lasciando che Git eseguisse il recupero, ma a un certo momento si è schiantato. Ciò significa che può essere un problema di connessione di rete. Controlla se tutto funziona correttamente: antivirus, firewall, ecc.

La risposta di elin3t è quindi importante perché ssh migliora le prestazioni del download in modo da evitare problemi di rete

L'impostazione della configurazione di seguito non funziona per me.

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

Come commento precedente, potrebbe essere il problema di memoria di Git. Quindi, provo a ridurre i thread di lavoro (da 32 a 8). In modo che non ottenga molti dati dal server contemporaneamente. Quindi aggiungo anche "-f" per forzare la sincronizzazione di altri progetti.

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

Quindi funziona bene ora.

repo sync -f -j8

Una risposta precedente consiglia l'impostazione su 512m. Direi che ci sono ragioni per pensare che sia controproducente su un'architettura a 64 bit. La documentazione per core.packedGitLimit dice:

L'impostazione predefinita è 256 MiB su piattaforme a 32 bit e 32 TiB (effettivamente illimitato) su piattaforme a 64 bit. Ciò dovrebbe essere ragionevole per tutti gli utenti / i sistemi operativi, ad eccezione dei progetti più grandi. Probabilmente non è necessario regolare questo valore.

Se vuoi provarlo controlla se è stato impostato e quindi rimuovi l'impostazione:

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

Si noti che Git 2.13.x / 2.14 (3 ° trimestre 2017) aumenta il valore predefinito core.packedGitLimitche influenza git fetch:
Il valore limite predefinito pacchetto è stato aumentato su piattaforme più grandi ( da 8 GiB a 32 GiB ) per salvare " git fetch" da un errore (recuperabile) mentre " gc" è in esecuzione in parallelo.

Vedi commit be4ca29 (20 apr 2017) di David Turner ( csusbdt) .
Aiutato da: Jeff King ( peff) .
^{(Unita da Junio ​​C Hamano - gitster- in commit d97141b , 16 maggio 2017)}

Aumentare core.packedGitLimit

Quando core.packedGitLimitviene superato, git chiuderà i pacchetti.
Se è in corso un'operazione di repack in parallelo con un fetch, il fetch potrebbe aprire un pacchetto e quindi essere costretto a chiuderlo a causa di hitGitLimit che viene colpito.
Il repack potrebbe quindi eliminare il pacchetto da sotto il recupero, causando il fallimento del recupero.

Aumentare core.packedGitLimitil valore predefinito per evitarlo.

Sulle attuali macchine x86_64 a 64 bit, sono disponibili 48 bit di spazio degli indirizzi.
Sembra che le macchine ARM a 64 bit non abbiano una quantità standard di spazio di indirizzamento (cioè, varia in base al produttore) e che le macchine IA64 e POWER hanno i 64 bit completi.
Quindi 48 bit è l'unico limite di cui possiamo ragionevolmente preoccuparci. Riserviamo alcuni bit dello spazio degli indirizzi a 48 bit per l'uso del kernel (questo non è strettamente necessario, ma è meglio essere sicuri), e usiamo fino ai restanti 45.
Nessun repository git sarà vicino così grande in qualsiasi momento presto, quindi questo dovrebbe prevenire l'errore.

Usando la risposta di @cmpickle, ho creato uno script per semplificare il processo di clonazione.

È ospitato qui: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Puoi eseguirlo usando la seguente riga:

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

Nel mio caso il problema non era nessuno dei parametri di configurazione di git ma il fatto che il mio repository avesse un file che superava la dimensione massima consentita sul mio sistema. Sono stato in grado di verificarlo provando a scaricare un file di grandi dimensioni e ottenendo un "Limite dimensioni file superato" su Debian.

Dopo di che ho modificato il mio file /etc/security/limits.conf aggiungendo alla fine le seguenti righe: * hard fsize 1000000 * soft fsize 1000000

Per "applicare" effettivamente i nuovi valori limite è necessario accedere nuovamente

Correlato tangenzialmente e utile solo nel caso in cui non si abbia accesso root ed estrarre manualmente Git da un RPM (con rpm2cpio) o altro pacchetto (.deb, ..) in una sottocartella. Caso d'uso tipico: si tenta di utilizzare una versione più recente di Git rispetto a quella obsoleta su un server aziendale.

Se il clone di git fallisce fatal: index-pack failed senza la menzione iniziale di EOF ma invece un messaggio di aiuto usage: git index-pack, c'è una mancata corrispondenza della versione ed è necessario eseguire git con il --exec-pathparametro:

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

Affinché ciò avvenga automaticamente, specificare in ~/.bashrc:

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

Ho avuto gli stessi log degli errori, usando git (v2.17.1) su ssh. Nel mio caso la soluzione è:

1. Accedi al repository git bare del mio server.
2. Chiama git gc.

Vedi la documentazione di git-gc: https://git-scm.com/docs/git-gc .

Per esempio:

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

Ora sono in grado di clonare questo repository senza errori, ad esempio sul lato client:

git clone git@my_server_url.com:my_repo_name

Il comando git gcpuò aiutare a chiamare sul lato client git per evitare git pushproblemi simili .

Un'altra soluzione (hack) sta scaricando l'ultimo master senza cronologia:

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

È possibile che non si verifichi un overflow del buffer.

Nel mio caso nulla ha funzionato quando il protocollo era https, poi sono passato a ssh e, assicurato, ho estratto il repository dall'ultimo commit e non dall'intera cronologia, e anche dal ramo specifico. Questo mi ha aiutato:

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

Nel frattempo ho disattivato tutti i download che stavo facendo, il che ha probabilmente liberato spazio e liberato la larghezza di banda

Il problema git-daemon sembra essere stato risolto in v2.17.0 (verificato con una v2.16.2.1 non funzionante). Vale a dire una soluzione alternativa alla selezione di testo nella console per "bloccare il buffer di output" non dovrebbe più essere richiesta.

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

• Correzioni assortite a "git daemon". (unisci ed15e58efe jk / daemon-fixes successivamente per mantenere).

Ho lo stesso problema. Seguendo il primo passaggio sopra sono stato in grado di clonare, ma non posso fare nient'altro. Impossibile recuperare, estrarre o estrarre vecchi rami.

Ogni comando viene eseguito molto più lentamente del solito, quindi muore dopo aver compresso gli oggetti.

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

Questo succede anche quando i tuoi ref usano troppa memoria. La potatura della memoria ha risolto questo problema per me. Basta aggiungere un limite a ciò che stai recuperando in questo modo ->

git fetch --depth=100

Questo recupererà i file ma con le ultime 100 modifiche nelle loro storie. Dopo questo, puoi eseguire qualsiasi comando bene e a velocità normale.

Ho provato la maggior parte delle risposte qui, ho riscontrato l'errore con il client PUTTY SSH con tutte le possibili costellazioni.

Una volta passato a OpenSSH, l'errore è scomparso (rimuovere la variabile di ambiente GIT_SSH e riavviare git bash).

Stavo usando una nuova macchina e le versioni git più recenti. Su molte altre macchine precedenti (anche AWS) ha funzionato come previsto anche con PUTTY senza alcuna configurazione git.

Ho riscontrato lo stesso problema. Il REPO era troppo grande per essere scaricato tramite SSH. Proprio come consigliato da @ elin3t, ho clonato su HTTP / HTTPS e modificato l'URL REMOTO in .git / config per utilizzare il REPO SSH.

Ho avuto lo stesso problema di seguito quando corro 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

Poi ho controllato il git status, Ci sono state così tante modifiche senza impegno che ho risolto il problema impegnando e inviando tutte le modifiche senza impegno.

Nessuna delle soluzioni sopra ha funzionato per me.

La soluzione che alla fine ha funzionato per me è stata la commutazione del client SSH. La variabile di ambiente GIT_SSH è stata impostata su OpenSSH fornita da Windows Server 2019. Versione 7.7.2.1

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

Ho semplicemente installato stucco, 0,72

choco install putty

E cambiato GIT_SSH in

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

Ho provato praticamente tutti i suggerimenti fatti qui, ma nessuno ha funzionato. Per noi il problema era di carattere e peggiorava tanto più crescevano i repository (sul nostro Jenkins Windows build slave).

Alla fine è stata la versione di ssh utilizzata da Git. Git è stato configurato per utilizzare una versione di Open SSH, specificata nel file .gitconfig degli utenti tramite la variabile core.sshCommand. La rimozione di quella linea l'ha risolto. Credo che questo sia perché Windows ora viene fornito con una versione più affidabile / compatibile di SSH che viene utilizzata per impostazione predefinita.

Questo ha funzionato per me, configurando il nameserver di Google perché non è stato specificato alcun nameserver standard, seguito dal riavvio della rete:

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

Da un clone git, stavo ottenendo:

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

Dopo aver riavviato la mia macchina, sono stato in grado di clonare il repo bene.

Se sei su Windows, potresti voler controllare che il clone di git fallisca con "index-pack" fallito? .

Fondamentalmente, dopo aver eseguito il git.exe daemon ...comando, selezionare del testo dalla finestra della console. Riprova a tirare / clonare, potrebbe funzionare ora!

Vedi questa risposta per maggiori informazioni.

Assicurati che sul tuo disco sia rimasto spazio sufficiente

Nessuno di questi ha funzionato per me, ma usando lo strumento integrato di Heroku ha funzionato.

heroku git:clone -a myapp

Documentazione qui: https://devcenter.heroku.com/articles/git-clone-heroku-app