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

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

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).

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

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.

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

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.

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!

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.

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

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

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

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.

En utilisant @cmpickle answer, j'ai construit un script pour simplifier le processus de clonage.

Il est hébergé ici: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Vous pouvez l'exécuter en utilisant la ligne suivante:

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

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

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

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.

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”

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.

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). C'est-à-dire que la sélection du texte dans la console pour "verrouiller le tampon de sortie" ne devrait plus être nécessaire.

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

• Correctifs variés pour "démon git". (fusionnez ed15e58efe jk / daemon-fixes plus tard pour maint).

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.

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.

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.

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.

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

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.

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

À 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.

Si vous êtes sous Windows, vous voudrez peut-être vérifier que le clone git échoue avec "pack d'index" a échoué? .

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

Voir cette réponse pour plus d'informations.

Assurez-vous que votre disque dispose de suffisamment d'espace

Rien de tout cela 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