5
votes

erreur: échec de la décompression à distance: eof avant la lecture complète de l'en-tête du pack

Avant cela, j'ai eu un problème error: object file is empty , mon ordinateur portable s'éteint soudainement. J'étais fixé avec ça . Mon dépôt local a été corrigé et j'essaie de tirer et de pousser vers le maître distant. Mais j'ai un problème comme celui-ci

$ git push -u origin master
Counting objects: 26, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (22/22), done.
fatal: unable to read c779d43453f63d871ba2a079b79f04558d9b0920
error: remote unpack failed: eof before pack header was fully read
error: failed to push some refs to 'git@bitbucket.org:xxxx/xxxx.git'

Comment réparer mon repo distant? Je ne peux pas pousser mon nouveau commit car le dépôt distant est cassé

Comment réparer unable to read c779d43453f63d871ba2a079b79f04558d9b0920 sur le unable to read c779d43453f63d871ba2a079b79f04558d9b0920 distant?

git

2 commentaires

Est-ce que stackoverflow.com/a/5860180/6309 vous aiderait?


j'ai été corrigé sur mon fichier avec git hash-object -w pages/promo.vue


5 Réponses :


1
votes

Votre référentiel local n'est pas corrigé, car ce message:

error: remote unpack failed: eof before pack header was fully read
error: failed to push some refs to 'git@bitbucket.org:xxxx/xxxx.git'

provenait de votre propre Git, alors qu'il essayait de regrouper les données à envoyer à la télécommande. (Le moyen de le savoir est qu'il n'est pas préfixé par remote: :.) Les erreurs restantes:

fatal: unable to read c779d43453f63d871ba2a079b79f04558d9b0920

en sont les conséquences.

Ce problème n'a en aucun cas affecté l' autre référentiel, vous pouvez donc créer un nouveau clone de l'autre référentiel et faire tout ce que vous pouvez pour extraire des données utiles de votre référentiel pas tout à fait fixe à ajouter au nouveau (bon) clone.


1 commentaires

j'ai été corrigé sur mon fichier avec git hash-object -w pages/promo.vue .



13
votes

J'ai eu une erreur similaire avec git 2.19.0 qui a été corrigée en mettant à jour vers git 2.20.1. Je crois que dans mon cas, git s'est écrasé en essayant de compresser un objet spécifique (il n'a obtenu que "Compression d'objets: 31%"), puis le serveur a renvoyé cette erreur en raison de l'échec du processus d'envoi.

J'espère que ça aidera quelqu'un.


2 commentaires

La mise à jour de git a également résolu le problème pour moi, mais c'était entre 2.20.1 et 2.21.0 pour moi. Ce qui me porte à croire qu'il ne s'agit pas d'un correctif dans la mise à jour, mais plutôt d'un paramètre qui est réinitialisé ou d'un cache effacé pendant le processus de mise à jour.


Pareil pour moi. Mise à niveau de Git Scm 2.19 à 2.21 et puis tout fonctionne comme un charme!



2
votes

Cela peut être dû à une taille / un nombre relativement important de fichiers dans le commit. Quand j'ai essayé avec la fermeture éclair, cela a fonctionné pour moi


1 commentaires

Comment essayez-vous avec la fermeture éclair? Y a-t-il un argument ou une configuration supplémentaire que vous pouvez ajouter à git push pour faire cela?



6
votes

J'ai eu ce problème pour moi dans un certain nombre de dépôts, je l'ai finalement retracé jusqu'aux dépôts stockés dans ma Dropbox et la "synchronisation sélective" appliquée. En conséquence, le dossier .git n'était pas entièrement disponible localement.

Aller dans le dossier dans le Finder et sélectionner la synchronisation sélective > local l'a corrigé.

Le dossier parent a été marqué pour être synchronisé, mais Dropbox semble supposer que les dossiers cachés ne sont probablement pas importants.


1 commentaires

Je peux attester que cela se produit, en fait. Grr, Dropbox.



1
votes

Cela m'est arrivé sur macOS Big Sur et la mise à niveau de ma version git l'a corrigé. La version initiale était 2.23.0, mise à niveau vers la version 2.29.2 de git.


0 commentaires