fatal: début de L'EOF fatal: échec du pack index

Question

fatal: début de L'EOF fatal: échec du pack index

j'ai googlé et j'ai 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 est dans le réseau LAN.

Exécuter cette commande à partir d'une autre machine provoque une erreur.

Mais exécuter la même commande clone en utilisant git: / / 192.168.8.5 ... sur le serveur, c'est bon 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 dans .gitconfig mais pas d'aide non plus.

Utilisation de la version 1.8.5.2 de git.msysgit.0

[core]
    compression = -1

171

cygwin git msysgit

demandé sur VonC 2014-01-22 12:32:17

17 réponses

dans mon cas, c'était très utile:

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

cela limitera la caisse à la branche mentionnée seulement, donc accélérera le processus.

Espérons que cela aidera.

3

répondu sMajeed 2017-08-04 05:57:50

dans mon cas, rien ne fonctionnait lorsque le protocole était https, puis je suis passé à ssh, et je me suis assuré, j'ai retiré le rapport du dernier commit et pas toute l'histoire, et aussi la branche spécifique. Cela m'a aidé:

git clone --profondeur de 1 "ssh:.git "-- branche "specific_branch "

0

répondu Shripada 2015-08-31 10:23:03

assurez-vous que votre lecteur a assez d'espace libre

0

répondu IndieTech Solutions 2016-03-11 17:32:59

noter que Git 2.13.x / 2.14 (Q3 2017) augmente la valeur par défaut core.packedGitLimit qui influence git fetch :

La valeur limite par défaut de packed-git a été augmentée sur les plates-formes plus grandes ( de 8 GiB à 32 GiB ) pour sauver " git fetch "d'une défaillance (récupérable) tandis que" gc " est en cours d'exécution en parallèle.

Voir commettre be4ca29 (20 Avril 2017) par David Turner ( csusbdt ) .

Aidé par: Jeff King ( peff ) .

^{(fusionné par Junio CA Hamano -- gitster -- in commit d97141b , 16 mai 2017)}

Augmenter core.packedGitLimit

lorsque core.packedGitLimit est dépassé, git ferme les paquets.

S'il y a une opération de reconditionnement en cours en parallèle avec un fetch, le fetch peut-être ouvrir un paquet, et puis être forcé de le fermer en raison de packedGitLimit être frappé.

Repack pourrait supprimer le pack sous le chercher, causant la chercher à l'échec.

Augmenter core.packedGitLimit 's valeur par défaut pour l'en empêcher.

sur les machines x86_64 64 bits actuelles, 48 bits d'espace d'adresse sont disponibles.

Il semble que les machines à bras 64 bits n'ont pas d'espace d'adresse standard (c'est-à-dire qu'il varie selon le fabricant), et que les machines à bras IA64 et les machines alimentées en courant ont l'espace total de 64 bits.

Donc 48 bits est la seule limite à laquelle nous pouvons raisonnablement nous soucier. Nous réservons quelques bits de l'espace d'adresse de 48 bits pour l'utilisation du noyau (ceci n'est pas strictement nécessaire, mais il est préférable d'être sûr), et utiliser jusqu'à 45.

Aucun dépôt git ne sera être n'importe où près de cette grande bientôt, donc cela devrait prévenir la défaillance.

0

répondu VonC 2017-05-16 20:27:55

j'ai éteint tous les téléchargements que je faisais dans l'intervalle, ce qui a libéré un peu d'espace probablement et nettoyé haut / bas de la bande passante

0

répondu Bartłomiej Wach 2017-12-02 21:32:08

git-daemon problème semble avoir été résolu dans v2.17.0 (vérifié avec un non travail v2.16.2.1). C'est-à-dire: il ne devrait plus être nécessaire de contourner la sélection de texte dans la console pour "verrouiller le tampon de sortie".

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

correspond à"git daemon". (fusionner ed15e58efe jk / daemon-correctifs plus tard, à maint).

0

répondu GreenMoose 2018-05-02 13:46:22

j'ai le même problème. Après la première étape ci-dessus, j'ai été capable de cloner, mais je ne peux rien faire d'autre. On ne peut pas aller chercher, tirer ou chercher de vieilles branches.

chaque commande court 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 aussi quand vos arbitres utilisent trop de mémoire. L'élagage de la mémoire a arrangé ça pour moi. Il suffit d'ajouter une limite à ce que vous récupérer comme ->

git fetch --depth=100

cela récupérera les fichiers mais avec les 100 dernières éditions dans leurs histoires. Après cela, vous pouvez faire une commande d'amende et à une vitesse normale.

0

répondu Vishav Premlall 2018-09-23 13:33:59

cela a fonctionné pour moi, la mise en place de Googles nameserver parce qu'aucun serveur de noms standard n'a été spécifié, suivie par redémarrer le réseau:

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

-1

répondu Luca Steeb 2015-02-23 15:04:49

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

-1

répondu jpadvo 2015-09-16 15:28:26

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 été capable de cloner l'amende.

-1

répondu Paul Sturgess 2016-08-16 11:56:53

si vous êtes sous Windows, vous pouvez vérifier le clone de git ne fonctionne pas avec "index-pack" défectueux? .

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

Voir cette réponse pour plus d'info.

-1

répondu user276648 2017-06-07 03:19:57

score 353 · Answer 1

premièrement, désactiver la compression:

git config --global core.compression 0

ensuite, faisons un clone partiel pour tronquer la quantité d'info qui descend:

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 tir régulier:

git pull --all

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

score 63 · Answer 2

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

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

score 5 · Answer 3

j'ai eu cette erreur quand git est sorti de mémoire.

libérer un peu de mémoire (dans ce cas: laisser un travail de compilation finir) et réessayer a fonctionné pour moi.

score 4 · Answer 4

j'ai essayé toutes ces commandes et aucune ne fonctionne pour moi, mais ce qui fonctionne est de changer le git_url en http à la place de SSH

si est le clone de commande :

git clone <your_http_or_https_repo_url>

sinon si vous tirez sur la pension existante, faites-le avec

git remote set-url origin <your_http_or_https_repo_url>

espérons que cela aide quelqu'un!

score 4 · Answer 5

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 qu'il peut être un réseau-problème de connexion. Vérifiez si tout fonctionne correctement: Antivirus, pare-feu, etc.

la réponse d'elin3t est donc importante parce que ssh améliore les performances du téléchargement afin que les problèmes de réseau puissent être évités

score 4 · Answer 6

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

extrait d'un filetage BitBucket:

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

puis j'ai essayé d'utiliser une meilleure compression et ça a marché!

git config --global core.compression 9

de la Documentation Git:

de base.la "compression de la 1519230920"

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..Neuf divers compromis vitesse / taille, 9 étant le plus lent.

Si cette offre une par défaut à d'autres variables de compression, comme core.looseCompression et pack.compression.

score 3 · Answer 7

dans mon cas, c'était très utile:

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

cela limitera la caisse à la branche mentionnée seulement, donc accélérera le processus.

Espérons que cela aidera.

score 0 · Answer 8

dans mon cas, rien ne fonctionnait lorsque le protocole était https, puis je suis passé à ssh, et je me suis assuré, j'ai retiré le rapport du dernier commit et pas toute l'histoire, et aussi la branche spécifique. Cela m'a aidé:

git clone --profondeur de 1 "ssh:.git "-- branche "specific_branch "

score 0 · Answer 9

assurez-vous que votre lecteur a assez d'espace libre

0

répondu IndieTech Solutions 2016-03-11 17:32:59

score 0 · Answer 10

noter que Git 2.13.x / 2.14 (Q3 2017) augmente la valeur par défaut core.packedGitLimit qui influence git fetch :

La valeur limite par défaut de packed-git a été augmentée sur les plates-formes plus grandes ( de 8 GiB à 32 GiB ) pour sauver " git fetch "d'une défaillance (récupérable) tandis que" gc " est en cours d'exécution en parallèle.

Voir commettre be4ca29 (20 Avril 2017) par David Turner ( csusbdt ) .

Aidé par: Jeff King ( peff ) .

^{(fusionné par Junio CA Hamano -- gitster -- in commit d97141b , 16 mai 2017)}

Augmenter core.packedGitLimit

lorsque core.packedGitLimit est dépassé, git ferme les paquets.

S'il y a une opération de reconditionnement en cours en parallèle avec un fetch, le fetch peut-être ouvrir un paquet, et puis être forcé de le fermer en raison de packedGitLimit être frappé.

Repack pourrait supprimer le pack sous le chercher, causant la chercher à l'échec.

Augmenter core.packedGitLimit 's valeur par défaut pour l'en empêcher.

sur les machines x86_64 64 bits actuelles, 48 bits d'espace d'adresse sont disponibles.

Il semble que les machines à bras 64 bits n'ont pas d'espace d'adresse standard (c'est-à-dire qu'il varie selon le fabricant), et que les machines à bras IA64 et les machines alimentées en courant ont l'espace total de 64 bits.

Donc 48 bits est la seule limite à laquelle nous pouvons raisonnablement nous soucier. Nous réservons quelques bits de l'espace d'adresse de 48 bits pour l'utilisation du noyau (ceci n'est pas strictement nécessaire, mais il est préférable d'être sûr), et utiliser jusqu'à 45.

Aucun dépôt git ne sera être n'importe où près de cette grande bientôt, donc cela devrait prévenir la défaillance.

score 0 · Answer 11

j'ai éteint tous les téléchargements que je faisais dans l'intervalle, ce qui a libéré un peu d'espace probablement et nettoyé haut / bas de la bande passante

score 0 · Answer 12

git-daemon problème semble avoir été résolu dans v2.17.0 (vérifié avec un non travail v2.16.2.1). C'est-à-dire: il ne devrait plus être nécessaire de contourner la sélection de texte dans la console pour "verrouiller le tampon de sortie".

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

correspond à"git daemon". (fusionner ed15e58efe jk / daemon-correctifs plus tard, à maint).

score 0 · Answer 13

j'ai le même problème. Après la première étape ci-dessus, j'ai été capable de cloner, mais je ne peux rien faire d'autre. On ne peut pas aller chercher, tirer ou chercher de vieilles branches.

chaque commande court 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 aussi quand vos arbitres utilisent trop de mémoire. L'élagage de la mémoire a arrangé ça pour moi. Il suffit d'ajouter une limite à ce que vous récupérer comme ->

git fetch --depth=100

cela récupérera les fichiers mais avec les 100 dernières éditions dans leurs histoires. Après cela, vous pouvez faire une commande d'amende et à une vitesse normale.

score -1 · Answer 14

cela a fonctionné pour moi, la mise en place de Googles nameserver parce qu'aucun serveur de noms standard n'a été spécifié, suivie par redémarrer le réseau:

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

score -1 · Answer 15

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

score -1 · Answer 16

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 été capable de cloner l'amende.

score -1 · Answer 17

si vous êtes sous Windows, vous pouvez vérifier le clone de git ne fonctionne pas avec "index-pack" défectueux? .

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

Voir cette réponse pour plus d'info.

Las etiquetas más populares

fatal: début de L'EOF fatal: échec du pack index

17 réponses

Augmenter `core.packedGitLimit`

Las etiquetas más populares

fatal: début de L'EOF fatal: échec du pack index

17 réponses

Augmenter core.packedGitLimit

Augmenter `core.packedGitLimit`