fatal: EOF précoce fatal: index-pack défaillant

J’ai googlé et trouvé beaucoup de solutions mais aucune ne fonctionne pour moi.

J’essaie de cloner à partir d’une machine en me connectant au serveur distant qui se trouve sur 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, ça va et ça marche.

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 dans .gitconfig mais aucune aide aussi.
Utiliser la version 1.8.5.2.msysgit.0 de git

 [core] compression = -1 

D’abord, désactivez la compression:

 git config --global core.compression 0 

Ensuite, faisons un clone partiel pour tronquer la quantité d’informations à venir:

 git clone --depth 1  

Lorsque cela fonctionne, allez dans le nouveau répertoire et récupérez le rest 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).

Cette erreur peut se produire pour les besoins de mémoire de git. Vous pouvez append ces lignes à votre fichier de configuration global git, à savoir .gitconfig dans $USER_HOME , afin de résoudre ce problème.

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

J’ai eu cette erreur quand git a manqué de mémoire.

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

J’ai essayé toutes ces commandes et aucune ne fonctionne pour moi, mais ce qui a fonctionné a été de changer le git_url en http au lieu de ssh

si la commande clone fait:

 git clone  

sinon, si vous tirez sur le repo existant, faites-le avec

 git remote set-url origin  

j’espère que cela aidera quelqu’un!

Dans mon cas, c’était un problème de connexion. J’étais connecté à un réseau wifi interne dans lequel j’avais un access limité aux ressources. Cela laissait 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

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

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

Dans mon cas, c’était très utile:

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

Cela limitera le passage à la succursale mentionnée uniquement, ce qui accélérera le processus.

J’espère que cela aidera.

Dans mon cas, rien ne fonctionnait lorsque le protocole était https, puis je suis passé à ssh, et je me suis assuré que je ne retirais pas le repo du dernier commit, ni l’historique complet, ni la twig spécifique. Cela m’a aidé:

git clone –depth 1 “ssh: .git” –branch “specific_branch”

Assurez-vous que votre lecteur dispose de suffisamment d’espace

Notez que Git 2.13.x / 2.14 (Q3 2017) core.packedGitLimit le core.packedGitLimit par défaut qui influence git fetch :
La valeur par défaut de la valeur pack-git a été augmentée sur les grandes plates-formes ( de 8 Gio à 32 Gio ) pour enregistrer ” git fetch ” en cas d’échec (récupérable) pendant que ” gc ” s’exécute en parallèle.

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

Augmenter core.packedGitLimit

Lorsque core.packedGitLimit est dépassé, git va fermer les packs.
Si une opération de reconditionnement est en cours en parallèle avec une extraction, la récupération peut ouvrir un pack, puis être obligé de la fermer en raison du fait que la propriété packingGitLimit soit atteinte.
Le repack pourrait alors supprimer le pack sous le fetch, provoquant l’échec de l’extraction.

Augmentez la valeur par défaut de core.packedGitLimit 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 ne disposent pas d’un espace d’adresse standard (c’est-à-dire qu’elles varient selon les fabricants) et que les machines IA64 et POWER ont les 64 bits complets.
Donc, 48 bits est la seule limite à laquelle nous pouvons raisonnablement nous attendre. Nous réservons quelques bits de l’espace d’adressage de 48 bits pour l’utilisation du kernel (ce n’est pas ssortingctement nécessaire, mais il vaut mieux être sûr), et utilisez les 45 autres.
Aucun référentiel git ne sera proche de cette taille de sitôt, donc cela devrait éviter l’échec.

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. Je ne peux pas aller chercher, tirer ou sortir de vieilles twigs.

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

I: \ dev [master +0 ~ 6 -0]> git fetch –unshallow remote: Comptage d’objects: 645483, terminé. remote: Objets compressés: 100% (136865/136865), terminé.

erreur: RPC a échoué; résultat = 18, code HTTP = 20082 MiB | 6,26 Mio / s

fatal: début EOF

fatal: l’extrémité distante a raccroché de manière inattendue

fatal: index-pack a échoué

Cela se produit également lorsque vos ref utilisent trop de mémoire. L’élagage de la mémoire a corrigé ceci pour moi. Ajoutez simplement une limite à ce que vous récupérez comme ça -> git fetch –depth = 100

Cela va chercher les fichiers mais avec les 100 dernières éditions dans leurs historiques. Après cela, vous pouvez faire n’importe quelle commande juste à la vitesse normale.

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

Le problème de git-daemon semble avoir été résolu dans la v2.17.0 (vérifié avec une v2.16.2.1 non fonctionnelle). La solution de rechange consistant à sélectionner du texte dans la console pour “verrouiller le tampon de sortie” ne devrait plus être requirejse.

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

  • Corrections assorties à “git daemon”. (fusionnez ed15e58efe jk / daemon-fixes plus tard pour maintenir).

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 

Aucun de ceux-ci n’a fonctionné pour moi, mais l’utilisation de l’outil intégré d’Heroku a fait l’affaire.

 heroku git:clone -a myapp 

Documentation ici: https://devcenter.heroku.com/articles/git-clone-heroku-app

D’un clone git, j’obtenais:

 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.

Si vous êtes sous Windows, vous pouvez vérifier que le clone de git a échoué avec “index-pack” a échoué? .

Fondamentalement, après avoir exécuté la commande git.exe daemon ... , sélectionnez du texte dans cette fenêtre de la console. Réessayez de tirer / cloner, ça pourrait marcher maintenant!

Voir cette réponse pour plus d’informations.