Git se bloque lors de l'écriture d'objets

100

J'essaye git push -u origin masteret ça tient juste à

Writing objects:  99% (219/220), 12.65 MiB | 97 KiB/s

La 12.65partie change. Lorsque je quitte le processus et que je l'exécute à nouveau, il reprend à 99% mais ne se termine jamais, comme avant.

Il n'a jamais été poussé avec succès. Ceci est le commit initial.

git

— mattalxndr
source

Où voulez-vous pousser? Utilisez-vous SSH ou un autre protocole?

— Paŭlo Ebermann du

25

Serait la mise en place de l' http.postbufferaide? stackoverflow.com/questions/6842687/…

— VonC

3

Le commentaire de VonC est trop facile à ignorer. Ça marche pour moi.

— Jeudi

1

Incroyable. Cela l'a fait aussi pour moi. Et nous sommes en 2018 maintenant. Et c'est SSH, pas HTTP. Et le dépôt entier est de 15 Mo. Et le serveur "distant" est localhost. Arrêtez de romantiser Git, les amis, s'il vous plaît! ;)

— Sz.

218

J'ai suivi les conseils de VonC:

git config --global http.postBuffer 524288000

Pour les références futures, sur la base des commentaires:

500 MB: 524288000 (as posted in the original answer)
1 GB: 1048576000
2 GB: 2097152000 (anything higher is rejected as 'out of range')

— Hugo Forte
source

4

omg, merci pour ça! m'arrachait les cheveux, et cela a résolu mes problèmes!

— Brett Thomas

3

@HugoForte L'augmentation de la mémoire tampon semblait résoudre mon écriture bloquée de fichiers, mais mon push git ne s'est jamais terminé (suspendu après Writing objects: 100%) - auparavant, il se bloquait à 25%, donc cela a clairement aidé. Cependant, j'avais toujours un comportement "bizarre". J'ai redémarré mon système et cela a semblé résoudre les choses ... FYI ... si quelqu'un rencontre toujours des problèmes après avoir augmenté sa mémoire tampon, le redémarrage de mon système a aidé dans ma situation (solution de la vieille école quand même mais un nouveau redémarrage a vraiment aidé).

— twknab

4

Quelqu'un peut-il expliquer d'où 524288000vient le nombre ?

— Ryre

6

@Ryre c'est 500 Mo

— Hugo Forte

1

Que Dieu vous bénisse et Stackoverflow, je serais un perdant complet sans,

— decoder7283

35

Cela se produisait à cause d'un fichier énorme et non ignoré dans le répertoire du dépôt. Oups.

ÉDITER

Le blocage était dû au fait que le téléchargement du fichier prenait beaucoup de temps. Le fichier n'était pas censé avoir été inclus dans le push.

ÉDITER

S'il est vrai qu'un fichier volumineux pourrait être la raison de ce problème, si vous ne pouvez pas ignorer le fichier en question ou si vous devez simplement le pousser, suivez cette réponse.

— mattalxndr
source

@TimoSolo Pourquoi ferais-je ça? J'étais celui avec le problème, et j'ai documenté le correctif exact. Assez simple.

— mattalxndr

4

Oui, votre solution consistait à supprimer le problème. Pour les autres personnes qui ont réellement besoin de pousser un gros fichier, la réponse de @ hugo-forte résout le problème. Vous n'êtes pas obligé , j'ai juste pensé que cela aiderait plus de gens - dans l'esprit de SO.

— TimoSolo

1

La question n'est pas "Comment puis-je valider, puis pousser un gros fichier?". C'est "Mon git push est sans fin. Pourquoi?" Si vous ne vous attendez pas à ce que la poussée prenne une éternité, alors vous n'avez probablement pas (comme moi) l'intention de valider cet énorme fichier.

— mattalxndr

3

@mattalxndr Lorsque la réponse acceptée a 1/8 des voix, vous devriez probablement la changer.

— NorCalKnockOut

1

@mattalxndr Aucune des deux réponses n'est parfaite. L'un identifie la cause et l'autre propose une solution. La réponse idéale identifierait la cause, expliquerait pourquoi elle a le résultat donné et proposerait les deux solutions alternatives. OMI, sur les options actuelles, la réponse d'Hugo Forte est supérieure car elle résoudra le problème, que vous vouliez ou non pousser le fichier. Il ne s'agit pas d'ignorer les personnes qui ont commis la même erreur que vous; il résout le problème pour eux autant que n'importe qui d'autre, mais leur laisse le soin de supprimer un fichier s'ils n'ont pas l'intention de le pousser.

— BZ1

7

J'ai eu le même problème avec (écrire des objets% 16) coincé puis fatal. J'ai résolu ce problème en enregistrant les modifications actuelles et en clonant un nouveau référentiel, puis en y copiant les fichiers modifiés.

Par exemple. Supposons que le référentiel actuel est A, alors tout ce que vous avez à faire est:

mv A B
git clone A
mv B/* A/
rm -rf B

Ensuite, engagez-vous et poussez et tout a bien fonctionné. Il a reconnu les fichiers déplacés comme modifiés :)

— Maha
source

Vous rencontriez un symptôme différent. Le mien n'avait pas d'erreurs fatales.

— mattalxndr

5

Dans mon cas, j'utilisais un dossier git avec de mauvais droits stockés sur le même lecteur qu'un dépôt, mais cela pourrait être la même chose avec ssh même si vous utilisez un utilisateur de connexion autorisé.

Vérifiez ensuite si vous disposez des droits appropriés pour écrire sur le repo distant.

Exemple:

Initier le repo local et distant

git init /tmp/src
git init --bare /tmp/dst
cd /tmp/src

Ajout d'un dépôt distant à l'origine

src > git remote add dest /tmp/dst

Problème de simulation

src > chmod -R 555 /tmp/dst

Ajouter un faux fichier et le pousser

src > touch a && git add a && git commit -m 'demo'
src > git push --set-upstream dest master
src > git push
Counting objects: 3, done.
Writing objects: 99% (2/3), 202 bytes | 0 bytes/s.

Git se bloque

Solution

src > chmod -R 775 /tmp/dst

— Naewis
source

2

Veuillez envisager d'ajouter quelques détails supplémentaires à votre réponse, merci.

— Mirza Sisic

1

Désolé. Est-ce mieux ?

— Naewis

3

Dans ma situation, c'était la taille du fichier. En ajoutant un fichier .gitignore avec les extensions requises, j'ai pu ignorer la plupart des fichiers indésirables à pousser.

— Skitty
source

2

Dans mon cas, j'avais une vitesse de téléchargement Internet lente et le fichier que je voulais pousser était gros, l'astuce consiste à utiliser git LFS (stockage de fichiers volumineux) qui est beaucoup plus patient pour télécharger de gros fichiers, vous pouvez trouver un tutoriel git LFS ici

— utilisateur3160702
source

1

git clean -f -nrésout mon problème. De nombreux fichiers non suivis ne sont pas détectés. Mais soyez prudent car cela supprimera les fichiers de votre répertoire

— Sherlock
source

3

Plus précisément, quels fichiers supprimera-t-il?

— Jazimov

1

Dans mon cas, j'essayais de pousser sans remplir les règles de mon entreprise. J'ai appris plus tard que nous devrions commencer nos messages de commit avec "MOBIL-XXXX" où XXXX est le numéro attribué aux développeurs dans Jira (un autre outil que nous utilisons pour suivre le processus de développement) par les analystes.

Assurez-vous de vérifier si votre entreprise a une règle de contrainte similaire.

— Onat Korucu
source

0

J'avais le même problème sur la machine Windows 10, le writing objects bloque, mais dans une situation un peu différente.

Le problème que j'avais n'était que lorsque j'essayais d'ajouter de nouveaux fichiers au référentiel. Si je mets à jour des fichiers qui existent déjà dans le référentiel, tout fonctionnait correctement et peu importe si la taille du fichier était grande ou non. J'essayais surtout d'ajouter de nouveaux scripts.

J'ai essayé toutes les autres solutions trouvées sur Internet mais rien n'a fonctionné dans mon cas et la dernière chose que j'ai essayée a fonctionné. Il semble que ce soit à cause de certaines autorisations Windows pour le lecteur et le dossier spécifiques qui empêchent l'application d'écrire dans ces dossiers spécifiques ou de mettre à jour les fichiers même lorsque je suis connecté avec un compte administrateur et que j'exécutais l'application en tant qu'administrateur. Donc cette commande:

attrib -r +s D:\foldername

a corrigé le problème pour moi.

Juste en le publiant ici, peut-être que quelqu'un a le même problème que le mien.

— h4rd4r7c0r3
source