fatale: EOF precoce fatale: pack di indice fallito

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

Sto provando a clonare da una macchina collegandomi al server remoto che si trova nella rete LAN.
L’esecuzione di questo comando da un’altra macchina causa l’errore.
Ma eseguendo il comando SAME clone usando git: //192.168.8.5 … sul server va bene e ha successo.

Qualche idea ?

[email protected] ~ $ 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 in .gitconfig ma non aiuto anche.
Usando la versione git 1.8.5.2.msysgit.0

 [core] compression = -1 

Innanzitutto, distriggers 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  

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 tecnico con msysgit nelle versioni 1.8.x che esacerba questi sintomi, quindi un’altra opzione è provare con una versione precedente di git (<= 1.8.3, penso).

Questo errore può verificarsi per esigenze di memoria di git. Puoi aggiungere queste linee al tuo file di configurazione git globale, che è .gitconfig in $USER_HOME , per risolvere questo problema.

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

Ho ricevuto questo errore quando git ha esaurito la memoria.

Liberare un po ‘di memoria (in questo caso: lasciare terminare un lavoro di compilazione) e provare di nuovo ha funzionato per me.

Ho provato tutti i comandi e nessuno funziona per me, ma ciò che funziona è stato cambiare il git_url in http invece ssh

se il comando clone fa:

 git clone  

altrimenti se stai tirando sul repository esistente, fallo con

 git remote set-url origin  

spero che questo aiuti qualcuno!

Nel mio caso si trattava di un problema di connessione. Ero connesso a una rete wifi interna, nella quale avevo un accesso limitato alle risorse. Stava lasciando andare il recupero ma a un certo punto 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 che i problemi di rete possano essere evitati

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

https://bitbucket.org/site/master/issues/13290/connection-to-bitbucketorg-closed-by

Nel mio caso questo è stato abbastanza utile:

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

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

Spero che questo ti sia d’aiuto.

Nel mio caso niente 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”

Assicurati che il tuo disco abbia spazio sufficiente

Si noti che Git 2.13.x / 2.14 (Q3 2017) aumenta il valore predefinito core.packedGitLimit che influenza git fetch :
Il valore limite predefinito del git packato è stato generato su piattaforms 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 ) .
Helped by: Jeff King ( peff ) .
(Unita da Junio ​​C Hamano – gitster – in commit d97141b , 16 maggio 2017)

Aumentare core.packedGitLimit

Quando core.packedGitLimit viene superato, git chiuderà i pacchetti.
Se è in corso un’operazione di repack in parallelo con un recupero, il recupero potrebbe aprire un pacchetto e quindi forzarlo a chiuderlo a causa del fatto che hitGitLimit viene colpito.
Il repack potrebbe quindi eliminare il pacchetto da sotto il recupero, facendo fallire il recupero.

Aumentare il valore predefinito di core.packedGitLimit per impedirlo.

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

Ho lo stesso problema. Dopo il primo passo sopra sono riuscito a clonare, ma non posso fare altro. Non è ansible recuperare, estrarre o controllare i 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: conteggio oggetti: 645483, fatto. remote: compressione di oggetti: 100% (136865/136865), fatto.

errore: RPC fallito; risultato = 18, codice HTTP = 20082 MiB | 6,26 MiB / s

fatale: inizio EOF

fatale: il telecomando si è bloccato inaspettatamente

fatale: index-pack fallito

Questo succede anche quando i tuoi ref usano troppa memoria. Potare la memoria ha risolto questo problema per me. Basta aggiungere un limite a ciò che si recupera 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 alla velocità normale.

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

Il problema git-daemon sembra essere stato risolto nella v2.17.0 (verificato con una v2.16.2.1 non funzionante). Cioè la soluzione alternativa di selezionare il testo in 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”. (unire ed15e58efe jk / daemon-ripara più tardi a maint).

Ciò ha funzionato per me, impostando il server dei nomi di Google perché non è stato specificato alcun server dei nomi 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 

Nessuno di questi ha funzionato per me, ma usare lo strumento integrato di Heroku ha fatto il trucco.

 heroku git:clone -a myapp 

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

Da un clone del 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 riuscito a clonare la repo fine.

Se sei su Windows, potresti voler controllare che git clone fallisca con “index-pack” fallito? .

Fondamentalmente, dopo aver eseguito il tuo git.exe daemon ... , seleziona del testo da quella finestra della console. Riprova a tirare / clonare, potrebbe funzionare solo ora!

Vedi questa risposta per maggiori informazioni.