Git, fatal : l'extrémité distante a raccroché de manière inattendue.

Question

Quand j'ai essayé d'exécuter

git push origin master --force

Je viens de recevoir

Counting objects: 2649, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1280/1280), done.
error: RPC failed; result=22, HTTP code = 413 | 116 KiB/s   
fatal: The remote end hung up unexpectedly
Writing objects: 100% (2504/2504), 449.61 MiB | 4.19 MiB/s, done.
Total 2504 (delta 1309), reused 2242 (delta 1216)
fatal: The remote end hung up unexpectedly
Everything up-to-date

Est-ce que cela a quelque chose à voir avec le fait de ne pas être sécurisé ? J'ai essayé de créer une clé publique comme dans la réponse de Fatal : le terminal distant a raccroché de manière inattendue. et le relancer, mais ça ne marche toujours pas. Est-ce que je n'utilise pas réellement la clé ? Si oui, comment puis-je l'utiliser ?

Answer 1

Le problème est dû aux paramètres de la mémoire tampon de git/https. Afin de le résoudre (tiré de Git échoue lorsqu'on pousse un commit vers github )

git config http.postBuffer 524288000

Et exécutez à nouveau la commande

Answer 2

Cause : La taille par défaut des fichiers postés par Git a été dépassée.

Solution :

Naviguez vers le dépôt.

Exécutez la commande suivante pour augmenter la mémoire tampon à 500 Mo après avoir navigué vers le référentiel :

git config http.postBuffer 524288000

Answer 3

Cela ressemble à Comment faire pour que github utilise par défaut ssh et non https pour les nouveaux dépôts ? . Cela vaut probablement la peine d'essayer de passer du protocole http à ssh :

$ git remote add origin git@github.com:username/project.git

Answer 4

Cette erreur peut également être déclenchée par droits d'écriture manquants sur le référentiel.

---

Mon cas concret s'est déroulé comme suit :

1. J'ai créé un repo avec le root utilisateur de mon serveur (via SSH).
2. J'ai installé un service git et a créé un git utilisateur linux qui doit gérer toutes les actions liées à git.
3. À ce moment-là, j'avais oublié que le repo avait été créé avec la commande root l'utilisateur en premier lieu, et le git L'utilisateur n'avait tout simplement pas les droits pour écrire quoi que ce soit dans le référentiel.

Answer 5

Dans notre cas, le problème était un clone qui a écrit un .git/config qui contenait une entrée url qui était une méthode d'accès en lecture seule. En changeant l'url du fichier :// à la méthode @ a réglé le problème.

Running git remote -v a éclairé la question.