fatal: tôt EOF fatal: échec de l'index-pack
J'ai cherché sur Google et trouvé de nombreuses solutions, mais aucune ne fonctionne pour moi.
J'essaie de cloner un ordinateur 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 cause une erreur.
Mais l’exécution de la commande SAME clone à l’aide de git: //192.168.8.5 ... sur le serveur est satisfaisante et réussie.
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 également.
Utilisation de la version 1.8.5.2.msysgit.0 de Git
[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 à venir:
git clone --depth 1 <repo_URI>
Quand 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 régulier:
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 une version antérieure de git (<= 1.8.3, je pense).
Cette erreur peut se produire pour des besoins en mémoire de git. Vous pouvez ajouter ces lignes à votre fichier de configuration global git, .gitconfig dans $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 toujours.
Ensuite, j'ai essayé d'utiliser une meilleure compression et cela a fonctionné!
git config --global core.compression 9
À partir de la documentation Git:
core.compression
Un entier -1..9, indiquant une compression par défaut niveau. -1 est la valeur par défaut de zlib.
0 signifie pas de compression et 1..9 sont divers compromis vitesse/taille, 9 étant le plus lent.
Si défini, ceci fournit un Par défaut, d'autres variables de compression, telles que core.looseCompression et pack.compression.
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 se terminer) et réessayer a fonctionné pour moi.
Dans mon cas, cela a été très utile:
git clone --depth 1 --branch $BRANCH $URL
Cela limitera la commande à la seule branche mentionnée, ce qui accélérera le processus.
J'espère que cela aidera.
J'ai essayé toutes ces commandes et aucune ne fonctionne pour moi, mais ce qui a bien fonctionné a été de changer le git_url en http au lieu de ssh
si la commande clone est faite:
git clone <your_http_or_https_repo_url>
sinon, si vous tirez sur un dépôt existant, faites-le avec
git remote set-url Origin <your_http_or_https_repo_url>
espérons que cela aide 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 accès limité aux ressources. Cela permettait à git de récupérer le fichier, mais à un moment donné, il s'est écrasé ... Cela peut donc ê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, ce qui évite les problèmes de réseau.
Comme @ingyhere a dit:
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 à venir:
git clone --depth 1 <repo_URI>
Quand 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 agence de suivi uniquement 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 chercher et git va tirer toutes vos branches distantes maintenant
Une réponse précédente recommande de régler sur 512m. Je dirais qu'il y a des raisons de penser que c'est contre-productif avec une architecture 64 bits. Le documentation pour core.packedGitLimit dit:
La valeur par défaut est de 256 Mo sur les plates-formes 32 bits et de 32 Tio (illimité) sur les plates-formes 64 bits. Cela devrait être raisonnable pour tous les utilisateurs/systèmes d'exploitation, à l'exception des projets les plus importants. Vous n'avez probablement pas besoin d'ajuster cette valeur.
Si vous voulez l'essayer, vérifiez si vous l'avez configuré puis supprimez le paramètre:
git config --show-Origin core.packedGitLimit
git config --unset --global core.packedGitLimit
Essayé la plupart des réponses ici, j'ai eu l'erreur avec le client SSH PuTTY avec toutes les constellations possibles.
Une fois je suis passé à OpenSSH l’erreur avait 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/anciennes machines (AWS également), cela fonctionnait comme prévu avec PuTTY également sans configuration git.
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 vérifier les vieilles branches.
Chaque commande est beaucoup plus lente 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 arbitres utilisent trop de mémoire. L'élagage de la mémoire a corrigé cela pour moi. Il suffit d’ajouter 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 leur historique . Après cela, vous pourrez exécuter n'importe quelle commande correctement et à une vitesse normale.
J'ai le même problème. Le REPO était trop gros pour être téléchargé via SSH. Comme @ elin3t recommandé, j'ai cloné sur HTTP/HTTPS et modifié l'URL REMOTE dans . Git/config pour utiliser le REPO SSH.
Le problème de git-daemon semble avoir été résolu dans v2.17.0 (vérifié avec une version v2.16.2.1 non opérationnelle) . I.e. La solution de contournement consistant à sélectionner du texte dans la console pour "verrouiller le tampon de sortie" ne devrait plus être nécessaire.
De https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt :
- Assortiment de correctifs pour "git daemon" . (fusionnez ed15e58efe jk/daemon-correctifs plus tard avec maint).
Dans mon cas, rien ne fonctionnait lorsque le protocole était https, puis je suis passé à ssh et je me suis assuré d'extraire le rapport de la dernière validation et non l'historique complet, mais aussi une branche spécifique. Cela m'a aidé:
clone de git --depth 1 "ssh: .git" - branche “specifique”
J'ai désactivé tous les téléchargements que je faisais entre-temps, ce qui a probablement libéré de l'espace et libéré de la bande passante.
Assurez-vous qu'il reste suffisamment d'espace sur votre disque.
J'ai le même problème que ci-dessous quand je lance 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 Push toutes les modifications non validées.
Notez que Git 2.13.x/2.14 (T3 2017) déclenche le core.packedGitLimit par défaut qui influence git fetch:
La valeur limite par défaut pour les paquets compressés a été augmentée sur de plus grandes plates-formes (de 8 GiB à 32 GiB) pour enregistrer le "git fetch" d'un fichier échec lorsque "gc" est exécuté en parallèle.
Voir commit be4ca29 (20 avril 2017) de David Turner (csusbdt) .
Aidé de: Jeff King (peff) .
(Fusion par Junio C Hamano - gitster - in commit d97141b , 16 mai 2017)
Augmenter
core.packedGitLimitLorsque
core.packedGitLimitest dépassé, git fermera les paquets.
S'il y a une opération de remballage en parallèle avec une extraction, l'extraction pourrait ouvrir un pack, puis être obligé de le fermer en raison de l'attaque de PackitGitLimit.
Le remballage peut alors supprimer le paquet de sous l'extraction, ce qui entraîne l'échec de l'extraction.Augmentez la valeur par défaut de
core.packedGitLimitpour éviter cela.Sur les machines x86_64 64 bits actuelles, un espace d'adressage de 48 bits est disponible.
Il semble que les machines 64 bits ARM ne disposent d'aucun espace d'adressage standard (c'est-à-dire qu'il varie selon les fabricants), tandis que les machines IA64 et POWER disposent de 64 bits complets.
Donc, 48 bits est la seule limite dont on puisse raisonnablement se soucier. Nous réservons quelques bits de l'espace d'adressage 48 bits à l'utilisation du noyau (ce n'est pas strictement nécessaire, mais il est préférable d'être sûr) et nous en utilisons jusqu'à 45.
Aucun référentiel git ne sera proche de cette taille dans un avenir proche, cela devrait donc empêcher l’échec.