Git, fatal: le terminal distant a raccroché de façon inattendue


278

Quand j'ai essayé de courir

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 quelque chose à voir avec le fait de ne pas être en sécurité? J'ai essayé de créer une clé publique comme dans la réponse de Fatal: l'extrémité distante a raccroché de manière inattendue et l'exécute à nouveau, mais cela ne fonctionne toujours pas. Suis-je pas vraiment en utilisant la clé? Si oui, comment l'utiliser?


veuillez afficher la sortie degit remote -v
CharlesB


13
git config http.postBuffer 524288000 # ça marche pour moi
Hari Das

si vous obtenez error: could not lock config file .git/config: No such file or directoryvoir stackoverflow.com/a/32329453/827525
niksmac

1
Je n'ai pu obtenir aucune des solutions suggérées pour travailler. Ensuite, j'ai essayé GitKraken. C'est l'un des rares programmes Git qui n'utilise pas git.exe. GitKraken pourrait le faire. Après que GitKraken ait poussé le référentiel, j'ai pu revenir à git.exe et synchroniser sans aucun problème.
lars pehrsson

Réponses:


83

Cela ressemble à Comment obtenir github par défaut sur ssh et non https pour les nouveaux référentiels . Il vaut probablement la peine d'essayer de passer du protocole http à ssh:

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

Pourquoi ne puis-je pas simplement passer de http à https?
DanielLC

10
bash-3.2 $ git remote add origin git@github.com: xxx / xx.git fatal: l'origine distante existe déjà. POURQUOI ?
almaruf

11
@almaruf c'est parce que la télécommande originest déjà là et que vous essayez de la remplacer. git ne le permet pas. Vous devez donc d'abord le faire, git remote rm originpuis réessayer. Cela fonctionnerait
Alfie

assurez-vous d'initialiser le projet s'il s'agit d'un nouveau clone frais avecgit init
Raul

vous pouvez utiliser le protocole git sur ssh (qui nécessite des clés ssh) ou le protocole https qui nécessite un nom d'utilisateur et un mot de passe via un jeton d'accès personnel - je préfère le dernier
Raul

521

Le problème est dû aux paramètres de tampon git / https. Pour le résoudre (extrait de Git échoue lors de la transmission de commit à github )

git config http.postBuffer 524288000

Et réexécutez la commande


4
J'ai besoin que le tampon soit supérieur à 500 Mo - est-ce possible? Cela ne semble pas faire de différence si j'augmente le nombre de postBuffer ...
jowie

Merci pour le lien - j'ai trié le problème en divisant la poussée en petits morceaux. Si j'ai à nouveau un problème, je sais où chercher!
jowie

17
Serait-ce une bonne idée de l'utiliser avec --global? Je traite régulièrement de grands référentiels.
DaAwesomeP

2
@ shivam13juna rien n'est jamais supprimé d'Internet: :) web.archive.org/web/20170119225336/http://github.com/gitlabhq/…
Roman M

3
J'ai exécuté "git config http.postBuffer 524288000", mais le problème n'est toujours pas résolu, il dit toujours la même chose, l'extrémité distante a raccroché de manière inattendue
Narendra

80

Cause: la taille de publication de fichier par défaut pour Git a été dépassée.

Solution :

Accédez au dépôt.

Exécutez la commande suivante pour augmenter le tampon à 500 Mo après avoir accédé au référentiel:

git config http.postBuffer 524288000

2
Veuillez formater votre code à l'aide des balises de code. Expliquez également ce que fait le code car il s'agit d'un ancien message, faites votre réponse aussi bien que possible.
Dan Grahn

31
Vous pouvez également l'utiliser git config ssh.postBuffer 524288000si vous publiez sur ssh au lieu de http.
John M

Pour certains casgit config --global http.postBuffer 100000000
Job M

Je reçois 'fatal: not in a git directory' après l'exécution de cette commande
ka3ak

@JohnM Cette option ne semble pas exister, elle n'est pas documentée dans la page de manuel
Personne le

29

Vous pourriez obtenir une erreur comme celle-ci

erreur: impossible de verrouiller le fichier de configuration .git / config: aucun fichier ou répertoire de ce type

c'est parce que vous n'avez pas de .git/configfichier local Vous pouvez le faire fonctionner avec cette commande

git config --global http.postBuffer 524288000


cela m'a aidé lors de la tentative de clonage sur un PC très lent à l'intérieur de cygwin - cela a continué à se
bloquer

Cela m'aide à résoudre le problème "fatal: l'extrémité distante a raccroché lors du premier contact".
Karthic.K

15

D'autres solutions n'ont pas fonctionné dans mon cas, faire un ramasse-miettes l'a corrigé pour moi:

git gc --aggressive


21
Cela a résolu mon problème, mais il a également écrasé les changements de HEAD détachés dans un état où leur fusion est devenue désagréable (tout a été converti en ADD). J'aurais aimé avoir fait des recherches sur celui-ci avant de le lancer.
MatrixManAtYrService

Comment cela pose problème?
Annadate Piyush

9

Contrairement à l'une des autres réponses - j'ai eu un problème de push avec ssh - je suis passé à https et il a été corrigé.

git remote remove origin
git remote add origin https://github..com/user/repo
git push --set-upstream origin master

8

Cette erreur peut également être générée par des autorisations d'écriture manquantes sur le référentiel.


Mon cas concret est allé comme ceci:

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

4

Coupable (dans mon cas):
un réseau à latence élevée.

Ce n'est pas une réponse en soi mais plutôt une observation qui peut aider les autres. J'ai trouvé que cette erreur apparaît occasionnellement sur les réseaux à latence élevée (je dois utiliser une antenne parabolique pour l'accès à Internet par exemple). La vitesse du réseau est correcte, mais la latence peut être élevée. Remarque: Le problème existe uniquement dans certains scénarios, mais je n'ai pas déterminé quel est le modèle.

Atténuation temporaire:
j'ai changé de réseau - je suis passé à un réseau cellulaire plus lent, mais à latence plus faible (mon téléphone utilisé comme point d'accès) - et le problème a disparu. Notez que je ne peux le faire que par itération car ma connectivité cellulaire est également intermittente. De plus, l'utilisation de la bande passante ajoute des coûts. J'ai aussi de la chance d'avoir cette option à ma disposition. Tout le monde ne le fait pas.

Je suis sûr qu'il y a un paramètre de configuration quelque part qui rend git - ou ssh ou curl ou tout ce qui arrive en premier - plus tolérant envers de tels réseaux, mais je ne sais pas ce que c'est.

Un appel aux développeurs:
ce type de problèmes est un problème constant pour les populations rurales. Pensez à nous lorsque vous concevez vos systèmes, outils et applications. Je vous remercie.


3

Dans notre cas, le problème était un clone qui a écrit un .git/configfichier contenant une entrée URL qui était une méthode d'accès en lecture seule. Changer l'URL de la ://méthode à la @méthode a résolu le problème.

La course à pied a git remote -véclairé le problème.


3

Si vous utilisez git pour Windows (et vous l'êtes probablement, si vous le faites sur une machine Windows), et qu'aucune des autres corrections ici n'a fonctionné pour vous, essayez d'aller sur https://github.com/git-for- windows / git / releases , et obtenir une version sur ou après la version 2.4.5. Je l'ai réparé pour moi.


3

Vous avez probablement cloné le référentiel dans un référentiel existant, pour résoudre le problème, vous pouvez simplement cloner le référentiel dans un autre répertoire et répliquer les modifications dans ce nouveau répertoire, puis exécuter le push.


nous avons un flux de travail bêta ansible et la reconstruction du site a causé exactement cela, clonant le référentiel au-dessus de l'autre. Chose impossible à résoudre mais qui pose un problème git. Merci :-)
Alejandro Moreno

2

Un autre ajout, car j'ai rencontré cette erreur d'une manière différente et Google m'a emmené ici.

Mon problème était une incompatibilité de cas; un camelCase et un pas. Apparemment, GIT vous empêche de faire cela sans vous dire pourquoi. Donc, si vos succursales sont différentes de la télécommande uniquement dans la capitalisation, essayez de les changer pour qu'elles soient identiques.

Voir: Git: 'Master ne peut pas être résolu en branche' après la fusion


Je pensais avoir inclus toutes les informations pertinentes - cela est dû à une incompatibilité de cas. J'ai ajouté une phrase pour être plus explicite, mais il ne s'agit pas vraiment du lien. Désolé si ce n'était pas clair.
Thomas

2

Cela peut se produire après la mise à jour de votre plateforme OSX.

Ouvrez Terminal et accédez à votre dossier .ssh, puis entrez ssh-add -K ~/.ssh/id_rsa


2

PLESK Nginx et GIT J'obtenais cette erreur sur plesk git et en poussant un grand dépôt avec (qui sait quoi) cela m'a donné cette erreur avec le code HTTP 413 et j'ai regardé le serveur suivant était Plesk et il avait nginx en cours d'exécution ainsi qu'apache2 donc j'ai regardé dans les journaux et trouvé l'erreur dans les journaux nginx

Suivi ce lien pour permettre à plesk de reconstruire la configuration avec un téléchargement de fichiers plus volumineux.

J'ai sauté la partie php pour git

Après cela, Git Push a fonctionné sans aucune erreur.


1

J'ai eu la même erreur au pull.
J'ai fait l'astuce "http.postBuffer". Cela l'a résolu, mais quand j'ai voulu pousser, j'ai rencontré à nouveau l'erreur.

Ce qui a résolu mon problème:
1. Le cloné dans un autre dossier avec une autre machine virtuelle. (Linux).
2. J'ai fait mes changements.
3. Je l'ai poussé avec la machine virtuelle d'origine où je ne pouvais pas pousser au départ. (Les fenêtres)


ce n'est pas un copain de solution!
Behrouz.M

2
Je sais que ce n'est pas une solution idéale, mais cela a résolu le problème dans mon cas. Cela peut encore sauver la vie lorsque toutes les autres réponses échouent, comme elles l'ont fait dans mon cas.
nopara73

1

J'ai eu cette erreur lorsque j'avais une paire de clés incorrecte en .ssh. L'ajout de la clé de pub à github (dans les paramètres) a résolu ce problème pour moi.


1

J'ai le même problème. J'ai remarqué sur la page Web de Git que l'URL du clone SSH a la structure suivante:

git@github.com:user/project.git

Je pourrais résoudre mon problème en changeant simplement le ":" par "/", comme suit:

git@github.com/user/project.git

cela peut être utile.


1

Il semble presque inutile d'ajouter une réponse, mais je combattais cela depuis des siècles quand j'ai finalement découvert que c'était Visual Studio Online qui souffrait d'une panne sporadique. Cela est devenu évident lorsque VS a continué à demander des crédits et le site Web de VSO a parfois donné un 500.

Counting objects: 138816, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (38049/38049), done.
error: unable to rewind rpc post data - try increasing http.postBuffer
error: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054
The remote end hung up unexpectedly/138816), 33.30 MiB | 3.00 KiB/s
Writing objects: 100% (138816/138816), 50.21 MiB | 3.00 KiB/s, done.
Total 138816 (delta 100197), reused 134574 (delta 96515)
fatal: The remote end hung up unexpectedly
Everything up-to-date

J'ai ensuite remis mon tampon de publication HTTP à 2 Mo, car je pense que cela fonctionne mieux avec de nombreux messages plus petits.

Luc


1

Il semble que ce soit l'une des mille choses.

Pour moi, je poussais initialement master et développais (master n'avait aucun changement) via SourceTree. Changer cela pour développer ne fonctionnait que.


1

J'étais confronté à une erreur similaire lors du téléchargement d'un grand dépôt, "fatal: l'extrémité distante a raccroché de façon inattendue" sans plus de détails.

Après beaucoup de recherches, voici ce que j'ai fait:

  • L'utilisation de SSH au lieu de HTTPS n'a pas résolu le problème.
  • Augmenter progressivement http.postBuffer jusqu'à une très grande valeur, toujours pas de chance.
  • J'ai compris que cela pouvait être dû à des fichiers volumineux dans le référentiel (car il s'agit d'un référentiel nouvellement migré de perforce), j'ai donc recréé le référentiel à l'aide de LFS, en définissant largeFileThreshold à 40 m, ce qui a considérablement réduit la taille du référentiel (de 3,5 G à 500M). Je pensais que cela résoudrait le problème, mais à ma grande surprise, je faisais toujours face à la même erreur.

Enfin, il m'est venu à l'esprit que j'utilisais peut-être un ancien client git, car je n'ai pas vu de messages d'erreur supplémentaires. J'ai mis à jour le client git vers la dernière version (2.20.1), et le tour est joué, l'erreur a disparu!


J'ai également eu ce problème exact (migration à partir de TFS cependant). J'ai mis à niveau de 2.19 à 2.20 et il a été corrigé, un examen rapide des notes de version n'a pas révélé le problème.
George Richardson

Je viens de passer à 2.20.1.windows.1 et cela ne me laissera toujours pas pousser vers le référentiel distant
Vidar

@Vidar Peut être vérifier les fichiers volumineux, GitHub a une limite stricte de 100 Mo help.github.com/articles/what-is-my-disk-quota ; Jetez un œil à la section "Examen manuel des fichiers volumineux dans votre référentiel" dans confluence.atlassian.com/bitbucket/… ; la page elle-même est une bonne lecture.
Mahmoud Hanafy

@MahmoudHanafy - merci - c'était un paramètre dans le web.config sur la taille maximale du fichier - augmentez cela et git se comporte et tout le monde est content! Ce n'est pas GitHub pour moi mais notre propre privé sur le site Bonobo.Git.Server.
Vidar

0

J'ai eu cette erreur quand j'ai mal orthographié mon nom de succursale distante


0

J'ai pu contourner ce problème en utilisant Git Shell.

Chaque référentiel de github.com vous donne des URL HTTPS / SSH / Subversion que vous pouvez utiliser pour télécharger à l'aide de Shell, voir ici: http://prntscr.com/8ydguv .
D'après les récents changements de GitHub, SSH semble être la meilleure méthode.

Commande à utiliser dans Shell:

git clone "URL of repo goes here w/ no quotes"

Que voulez-vous dire par «Git Shell»? Vous utilisez gitdans un terminal?
Karl Richter

0

Faites cela pour voir la clé que vous utilisez; ssh -vT git@github.digitalglobe.com

Assurez-vous ensuite que dans votre build, vous avez cette exécution au début. eval "$ (ssh-agent -s)" ssh-add ~ / .ssh / id_rsa


0

1) cd dans le répertoire du projet

2) git status

3) git checkout -f HEAD

4) Confirmez le succès en tirant à nouveau vers le bas pour vous assurer que vous êtes à jour si votre repo semblait incomplet

Cela fonctionne si vous obtenez l'erreur en question de Git de Visual Studio lors du clonage d'un dépôt à partir de Bitbucket


0

Cela peut également se produire si l'un des commits que vous appuyez est mal formé.

J'ai (sans le savoir) un commit avec un champ de courrier électronique d'auteur mal formé, mais tout ce que je recevais était ce vague remote end hung upmessage d'erreur. J'ai pu pousser d'autres branches, mais pas celle- ci , j'ai donc commencé à pousser les commits de la "mauvaise" branche une par une jusqu'à ce que j'arrive finalement à:

Pushing to git@github.com:directangular/unicorn.git
Counting objects: 100% (9/9), done.
Delta compression using up to 20 threads
Writing objects: 100% (5/5), 549 bytes | 549.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: error: object 74c7584ff0b93591c19d3a3c19695889dd2274d2: badEmail: invalid author/committer line - bad email        
remote: fatal: fsck error in packed object        
error: remote unpack failed: index-pack abnormal exit
To github.com:directangular/unicorn.git
 ! [remote rejected]       pizzafeast -> pizzafeast (failed)
error: failed to push some refs to 'git@github.com:directangular/unicorn.git'

Il semble donc que l' remote end hung up unexpectedlyerreur "sorte d'avaler" le message d'erreur réel, qui est probablement une sorte de commit mal formé comme je l'ai ici.

Après avoir corrigé l'e-mail mal formé, j'ai pu pousser très bien.


0

Je ne pense pas que ce soit une bonne idée de le faire, mais si vous avez une sauvegarde dans votre machine .. appuyez une fois de plus, puis essayez de cloner le dépôt, puis supprimez .git de l'ancien répertoire et déplacez .git du nouveau dossier cloné .. git est résolu mais en raison du problème, certains fichiers peuvent ne pas être téléchargés sur git. Poussez à nouveau tout de ur vers le haut, puis tirez-le vers votre serveur ou l'autre machine où il se trouve. En ce moment, je viens de faire ça ... ça marche pour moi .. et prenez une copie de sauvegarde de votre répertoire avant de faire ça.

Et plz me corriger si je me trompe. Je ne sais pas non plus ce qui peut mal tourner après avoir fait ça? Mais cette fois, cela fonctionne vraiment.


0

mon problème (fatal: l'extrémité distante a raccroché de manière inattendue) a été résolu en vérifiant l'autorisation et le propriétaire du référentiel.

Le propriétaire des fichiers du référentiel git doit être l'utilisateur avec lequel vous souhaitez pousser / tirer / cloner.


0

Aucune des réponses ci-dessus n'a fonctionné pour moi, mais voici ce qui a fonctionné.

1) supprimer .git/de votre projet
2) cloner le référentiel distant vers un nouvel emplacement comme votre bureau. git clone https://github.com/foo/bar.git
3) déplacer .git/du nouvel emplacement vers l'ancien emplacement
4) réengager et pousser vos modifications


0

La cause du problème pour moi était les paramètres réseau: j'ai une carte wifi "Killer" qui, apparemment, détruit les paquets réseau d'une manière que SSH et SSL n'aiment pas.

Pour résoudre le problème, j'ai dû aller dans "Killer Control Center", "Paramètres" et désactiver "Advanced Stream Detect" - les commandes git ont recommencé à fonctionner instantanément.


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.