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

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.

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

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.

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:

1. mv A B
2. git clone A
3. mv B/* A/
4. rm -rf B

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

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

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.

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

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

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.

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.