fatal: EOF précoce fatal: échec du pack d'index


271

J'ai googlé et trouvé de nombreuses solutions, mais aucune ne fonctionne pour moi.

J'essaye de cloner d'une machine en me connectant au serveur distant qui est dans le réseau LAN.
L'exécution de cette commande à partir d'une autre machine provoque une erreur.
Mais exécuter la commande SAME clone en utilisant git: //192.168.8.5 ... sur le serveur, c'est correct et réussi.

Des idées ?

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

J'ai ajouté cette configuration .gitconfigmais pas d'aide aussi.
Utilisation de la version git 1.8.5.2.msysgit.0

[core]
    compression = -1

8
J'ai rencontré ce problème pendant 2-3 jours lorsque j'essayais de cloner à partir d'un VPN. dans mon cas, le problème était la bande passante réseau. i corrigé par clonage dans un réseau haute vitesse.
Avijit Nagare

1
J'ai également remarqué que c'est lié au réseau.
me demande

1
J'ai eu cette erreur parce que mes amis ne connaissent pas si bien git et poussent beaucoup d'images dans le dépôt! =))
Clite Tailor

J'ai également remarqué que c'est lié au réseau. J'ai également corrigé par clonage en réseau haut débit.
shashaDenovo

Réponses:


506

Tout d'abord, désactivez la compression:

git config --global core.compression 0

Ensuite, faisons un clone partiel pour tronquer la quantité d'informations qui descend:

git clone --depth 1 <repo_URI>

Lorsque cela fonctionne, allez dans le nouveau répertoire et récupérez le reste du clone:

git fetch --unshallow 

ou, alternativement,

git fetch --depth=2147483647

Maintenant, faites une traction régulière:

git pull --all

Je pense qu'il y a un problème avec msysgit dans les versions 1.8.x qui exacerbe ces symptômes, donc une autre option est d'essayer avec une version antérieure de git (<= 1.8.3, je pense).


6
Merci, cela a très bien fonctionné. J'avais essayé de changer le http.postbuffer qui ne fonctionnait pas, mais après avoir fait comme indiqué dans cette réponse, cela a très bien fonctionné. Je n'ai pas utilisé la ligne "git fetch --depth = 2147483647", mais j'ai utilisé le reste.
Nick Benedict

2
@ EthenA.Wilson Vous devez ensuite transmettre l'URL distante du référentiel. Par exemple git clone --depth 1 git@host:user/my_project.git.
Nathan Gould

6
@Jose A. - J'ai rencontré ce problème lorsque j'étais sur une version plus récente de msysgit. Si vous êtes sur msysgit, essayez une version plus ancienne (<= 1.8.3). Sinon, essayez git fetch --depth 1000 (puis 2000, etc., en augmentant progressivement jusqu'à ce que tous les fichiers soient extraits).
ingyhere

2
@Jose A. - Jetez également un œil à ceci: stackoverflow.com/questions/4826639/…
ingyhere

2
Salut cher ami. Merci pour votre excellente solution. Mais le dernier git pull --allne fonctionne pas. En raison de git clone --depth 1ne définir la plage de récupération qu'une seule branche. Nous devons donc d'abord éditer .git / config.
pjincz

93

Cette erreur peut se produire pour les besoins en mémoire de git. Vous pouvez ajouter ces lignes à votre fichier de configuration git global, qui se trouve .gitconfigdans $USER_HOME, afin de résoudre ce problème.

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

Cela a fonctionné pour moi - même si j'avais encore besoin de plusieurs tentatives, mais sans ce changement, l'avortement est arrivé à 30%, ensuite à 75% ... et une fois, il est passé à 100% et a fonctionné. :)
peschü

Doit être la réponse sélectionnée
Asim Qasımzade

Sur Windows, avec git 2.19, cela l'a corrigé. Ajout spécifique des paramètres liés au pack.
Καrτhικ

Travaillé! Merci!
Guille Acosta

ne travaille toujours pas pour moi 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

finalement résolu par git config --global core.compression 9

À partir d'un fil de discussion BitBucket:

J'ai essayé presque cinq fois, et ça arrive encore.

Ensuite, j'ai essayé d'utiliser une meilleure compression et cela a fonctionné!

git config --global core.compression 9

Depuis la documentation Git:

core.compression
Un entier -1..9, indiquant un niveau de compression par défaut. -1 est la valeur par défaut de zlib.
0 signifie pas de compression et 1..9 sont différents compromis vitesse / taille, 9 étant le plus lent.
S'il est défini, cela fournit une valeur par défaut à d'autres variables de compression, telles que core.looseCompression et pack.compression.


3
Besoin de fonctionner git repacken combinaison avec cette solution et cela a fonctionné.
erikH

Cela a fonctionné, n'a même pas essayé d'autres solutions car celle-ci est la plus courte et la plus élégante. devrait être acceptée réponse!
metablaster

Cela fonctionne aussi pour moi, via VPN et proxy d'entreprise. --compression 0n’a pas fonctionné ni tous les .gitconfigchangements suggérés ci-dessus.
Terrence Brannon

20

Comme l'a dit @ingyhere:

Clone peu profond

Tout d'abord, désactivez la compression:

git config --global core.compression 0

Ensuite, faisons un clone partiel pour tronquer la quantité d'informations qui descend:

git clone --depth 1 <repo_URI>

Lorsque cela fonctionne, allez dans le nouveau répertoire et récupérez le reste du clone:

git fetch --unshallow

ou, alternativement,

git fetch --depth=2147483647

Maintenant, faites un pull:

git pull --all

Ensuite, pour résoudre le problème de votre succursale locale, seul le maître de suivi

ouvrez votre fichier de configuration git ( .git/config) dans l'éditeur de votre choix

Où il est dit:

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

changer la ligne

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

à

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

Faites un git fetch et git va tirer toutes vos branches distantes maintenant


Cela fonctionne, mais j'ai laissé la compression à 9 et non à 0, ce qui a échoué.
metablaster

9

Dans mon cas, cela a été très utile:

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

Cela limitera le paiement à la branche mentionnée uniquement, accélérera donc le processus.

J'espère que cela vous aidera.


6

J'ai essayé toutes ces commandes et aucune ne fonctionne pour moi, mais ce qui fonctionnait était de changer le git_url en http à la place ssh

si la commande clone fait:

git clone <your_http_or_https_repo_url> 

sinon si vous tirez sur le référentiel existant, faites-le avec

git remote set-url origin <your_http_or_https_repo_url>

j'espère que cela aide quelqu'un!


1
Cette question concerne vraiment le message d'erreur dans la sortie ci-dessus lorsqu'il y a un problème de synchronisation de gros morceaux de fichiers à partir d'un référentiel connecté. Vous dites que le passage à https de ssh a permis au clone de terminer?
ingyhere

Oui! Ça marche pour moi, j'ai un repo 4 Go + et la seule solution que j'ai eue c'est que ça!
elin3t

2
Cela fonctionne pour moi, merci! Clonez par https, puis redéfinissez la télécommande sur ssh.
Tuan

1
J'aimerais vraiment savoir pourquoi cela a fonctionné. Y a-t-il quelque chose dans le protocole SSH qui étouffe les gros objets que HTTPS ne fait pas? Est-ce un problème de couche transport?
bdetweiler

6

J'ai eu cette erreur lorsque git a manqué de mémoire.

Libérer de la mémoire (dans ce cas: laisser un travail de compilation se terminer) et réessayer a fonctionné pour moi.


Pour moi, il n'y avait pas beaucoup de mémoire disponible, en libérer et réessayer l'a résolu.
Martin Cassidy

4

Dans mon cas, c'était un problème de connexion. J'étais connecté à un réseau wifi interne, dans lequel j'avais un accès limité aux ressources. C'était laisser git faire le fetch mais à un certain moment, il s'est écrasé. Cela signifie que cela peut être un problème de connexion réseau. Vérifiez si tout fonctionne correctement: antivirus, pare-feu, etc.

La réponse de elin3t est donc importante car ssh améliore les performances du téléchargement afin d'éviter les problèmes de réseau


4

La configuration ci-dessous ne fonctionne pas pour moi.

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

Comme commentaire précédent, il pourrait s'agir du problème de mémoire de git. Ainsi, j'essaie de réduire les threads de travail (de 32 à 8). Pour qu'il n'obtienne pas beaucoup de données du serveur en même temps. Ensuite, j'ajoute également "-f" pour forcer la synchronisation d'autres projets.

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

Ensuite, cela fonctionne bien maintenant.

repo sync -f -j8

2

Une réponse précédente recommande de définir à 512 m. Je dirais qu'il y a des raisons de penser que c'est contre-productif sur une architecture 64 bits. La documentation de core.packedGitLimit dit:

La valeur par défaut est 256 Mo sur les plates-formes 32 bits et 32 ​​TiB (effectivement illimité) sur les plates-formes 64 bits. Cela devrait être raisonnable pour tous les utilisateurs / systèmes d'exploitation, sauf sur les plus gros projets. Vous n'avez probablement pas besoin d'ajuster cette valeur.

Si vous souhaitez l'essayer, vérifiez si vous l'avez défini, puis supprimez le paramètre:

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

1

Notez que Git 2.13.x / 2.14 (Q3 2017) augmente la valeur par défaut core.packedGitLimitqui influe sur git fetch:
la valeur limite par défaut de pack-git a été augmentée sur les plates-formes plus grandes ( de 8 Gio à 32 Gio ) pour sauver " git fetch" d'une panne (récupérable) tandis que " gc" fonctionne en parallèle.

Voir commit be4ca29 (20 avril 2017) par David Turner ( csusbdt) .
Aidé par: Jeff King ( peff) .
(Fusionné par Junio ​​C Hamano - gitster- en commit d97141b , 16 mai 2017)

Augmenter core.packedGitLimit

Quand core.packedGitLimitest dépassé, git fermera les packs.
S'il y a une opération de reconditionnement en parallèle avec une extraction, celle-ci peut ouvrir un pack, puis être forcée de le fermer en raison de la frappe de packGitLimit.
Le reconditionnement pourrait alors supprimer le pack sous la récupération, provoquant l'échec de la récupération.

Augmentez core.packedGitLimitla valeur par défaut pour éviter cela.

Sur les machines x86_64 64 bits actuelles, 48 ​​bits d'espace d'adressage sont disponibles.
Il semble que les machines ARM 64 bits n'ont pas d'espace d'adressage standard (c'est-à-dire qu'il varie selon le fabricant), et les machines IA64 et POWER ont les 64 bits complets.
Donc, 48 bits est la seule limite dont nous pouvons raisonnablement nous soucier. Nous nous réservons quelques morceaux de l'espace d'adressage 48 bits pour l'utilisation du noyau (ce n'est pas strictement nécessaire, mais il est préférable d'être en sécurité), et utiliser jusqu'à restants 45.
Aucun dépôt git sera partout près de ce grand tout moment bientôt, donc cela devrait empêcher l'échec.



1

Dans mon cas, le problème n'était pas lié aux paramètres de configuration de git, mais au fait que mon référentiel avait un fichier dépassant la taille de fichier maximale autorisée sur mon système. J'ai pu le vérifier en essayant de télécharger un gros fichier et en obtenant une "Limite de taille de fichier dépassée" sur Debian.

Après cela, j'ai édité mon fichier /etc/security/limits.conf en ajoutant et à la fin de celui-ci les lignes suivantes: * hard fsize 1000000 * soft fsize 1000000

Pour réellement «appliquer» les nouvelles valeurs limites dont vous avez besoin pour vous reconnecter


1

Tangentiellement lié et utile uniquement si vous n'avez pas d'accès root et extrayez manuellement Git d'un RPM (avec rpm2cpio) ou d'un autre package (.deb, ..) dans un sous-dossier. Cas d'utilisation typique: vous essayez d'utiliser une version plus récente de Git sur celle obsolète sur un serveur d'entreprise.

Si git clone échoue fatal: index-pack failed sans mention EOF précoce mais à la place un message d'aide à propos usage: git index-pack, il y a une incompatibilité de version et vous devez exécuter git avec le --exec-pathparamètre:

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

Pour que cela se produise automatiquement, spécifiez dans votre ~/.bashrc:

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

1

J'ai eu les mêmes journaux d'erreurs, en utilisant git (v2.17.1) sur ssh. Dans mon cas, la solution est:

  1. Entrez dans le référentiel git bare de mon serveur.
  2. Appelle git gc.

Voir la documentation de git-gc: https://git-scm.com/docs/git-gc .

Par exemple:

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

Maintenant, je peux cloner ce référentiel sans erreur, par exemple côté client:

git clone git@my_server_url.com:my_repo_name

La commande git gcpeut aider à être appelée côté client git pour éviter un git pushproblème similaire .


Une autre solution (hack) télécharge le dernier maître sans historique:

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

Il existe un risque qu'un débordement de tampon ne se produise pas.


0

Dans mon cas, rien ne fonctionnait lorsque le protocole était https, puis je suis passé à ssh et je me suis assuré que je retirais le dépôt du dernier commit et non de l'historique complet, et aussi d'une branche spécifique. Cela m'a aidé:

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


0

J'ai désactivé tous les téléchargements que je faisais entre-temps, ce qui a probablement libéré de l'espace et dégagé la bande passante.



0

J'ai le même problème. Après la première étape ci-dessus, j'ai pu cloner, mais je ne peux rien faire d'autre. Impossible de récupérer, de tirer ou de retirer les anciennes branches.

Chaque commande s'exécute beaucoup plus lentement que d'habitude, puis meurt après avoir compressé les objets.

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

Cela se produit également lorsque vos références utilisent trop de mémoire. L'élagage de la mémoire a corrigé cela pour moi. Ajoutez simplement une limite à ce que vous allez chercher ->

git fetch --depth=100

Cela récupérera les fichiers mais avec les 100 dernières modifications dans leurs historiques. Après cela, vous pouvez exécuter n'importe quelle commande très bien et à vitesse normale.


que veux-tu dire par TED?
Vishav Premlall

cette "réponse" aurait dû être un commentaire sur la réponse de @ingyhere.
mc0e

0

J'ai essayé la plupart des réponses ici, j'ai eu l'erreur avec le client PUTTY SSH avec toutes les constellations possibles.

Une fois que je suis passé à OpenSSH, l'erreur a disparu (supprimez la variable d'environnement GIT_SSH et redémarrez git bash).

J'utilisais une nouvelle machine et les dernières versions de git. Sur de nombreuses autres machines / anciennes (AWS également), cela fonctionnait comme prévu avec PUTTY sans aucune configuration git.


0

J'ai rencontré le même problème. Le REPO était trop gros pour être téléchargé via SSH. Tout comme @ elin3t recommandé, j'ai cloné sur HTTP / HTTPS et changé l'URL À DISTANCE dans .git / config pour utiliser le SSH REPO.


0

J'ai le même problème que ci-dessous lorsque je cours 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

Ensuite, j'ai vérifié le git status, Il y avait tellement de modifications non validées que j'ai résolu le problème en validant et en poussant toutes les modifications non validées.


0

Aucune des solutions ci-dessus n'a fonctionné pour moi.

La solution qui a finalement fonctionné pour moi était de changer de client SSH. La variable d'environnement GIT_SSH a été définie sur OpenSSH fourni par Windows Server 2019. Version 7.7.2.1

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

J'ai simplement installé du mastic, 0,72

choco install putty

Et changé GIT_SSH en

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


0

J'ai essayé à peu près toutes les suggestions faites ici mais aucune n'a fonctionné. Pour nous, le problème était capricieux et est devenu de pire en pire à mesure que les dépôts augmentaient (sur notre esclave de génération Jenkins Windows).

Cela a fini par être la version de ssh utilisée par git. Git a été configuré pour utiliser une version d'Open SSH, spécifiée dans le fichier .gitconfig des utilisateurs via la variable core.sshCommand. Supprimer cette ligne l'a corrigé. Je pense que c'est parce que Windows est désormais livré avec une version plus fiable / compatible de SSH qui est utilisée par défaut.


-1

Cela a fonctionné pour moi, en configurant le serveur de noms Googles car aucun serveur de noms standard n'a été spécifié, suivi du redémarrage du réseau:

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

-1

À partir d'un clone git, je recevais:

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

Après avoir redémarré ma machine, j'ai pu cloner l'amende de repo.


La première fois, je ne peux pas croire que le redémarrage de votre machine puisse résoudre ce problème, mais j'ai essayé tous les messages que je n'ai pas pu fonctionner. j'ai donc décidé de redémarrer ma machine est ma dernière solution pour moi. Heureusement pour moi, lorsque la machine démarre, j'essaie de nouveau de cloner. Je ne peux pas y croire. Ça marche !!!!!!!
Thxopen



En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.