L'extrémité distante s'est arrêtée de manière inattendue pendant le clonage git.

Question

Mon git échoue de manière répétée avec l'erreur suivante après avoir essayé de cloner le référentiel pendant un certain temps.

Quel pourrait être le problème ici ?

Note : J'ai enregistré ma clé SSH auprès de l'hébergeur de GIT.

Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly

Answer 1

Solution rapide :

Avec ce type d'erreur, je commence généralement par relever le niveau de l'erreur postBuffer taille par :

git config --global http.postBuffer 524288000

(certains commentaires ci-dessous rapportent avoir dû doubler la valeur) :

git config --global http.postBuffer 1048576000

(Pour npm publish , Martin Braun rapports dans les commentaires en le fixant à un maximum de 50 000 000 au lieu de 1 000 000 par défaut)

Plus d'informations :

De la git config page de manuel , http.postBuffer est à propos :

Taille maximale en octets du tampon utilisé par les transports HTTP intelligents lors du POST de données vers le système distant.
Pour les requêtes dont la taille est supérieure à celle du tampon, les protocoles HTTP/1.1 et Transfer-Encoding: chunked est utilisé pour éviter de créer localement un fichier pack massif. La valeur par défaut est de 1 MiB, ce qui est suffisant pour la plupart des demandes.

Même pour le clone, cela peut avoir un effet, et dans ce cas, le OP Joe rapports :

[clone] fonctionne bien maintenant

---

Remarque : si quelque chose s'est mal passé du côté du serveur, et si le serveur utilise Git 2.5+ (Q2 2015), le message d'erreur peut être plus explicite.
Voir " Clonage Git : le terminal distant s'est bloqué de manière inattendue, j'ai essayé de modifier les paramètres suivants postBuffer mais toujours en échec ".

---

Kulai ( dans les commentaires ) fait remarquer à cette page Git de dépannage d'Atlassian qui ajoute :

Error code 56 indique qu'un curl reçoit l'erreur de CURLE_RECV_ERROR ce qui signifie qu'un problème a empêché la réception des données pendant le processus de clonage.
Ce problème est généralement dû à un paramètre réseau, un pare-feu, un client VPN ou un antivirus qui interrompt la connexion avant que toutes les données aient été transférées.

Il mentionne également la variable d'environnement suivante, afin de faciliter le processus de débogage.

# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

---

Avec Git 2.25.1 (fév. 2020), vous en savez plus à ce sujet http.postBuffer "solution".

Voir commettre 7a2dc95 , commettre 1b13e90 (22 janvier 2020) par brian m. carlson ( bk2204 ) .
(fusionné par Junio C Hamano -- gitster -- sur commettre 53a8329 , 30 janvier 2020)
( Discussion sur la liste de diffusion Git )

docs : mentionner quand augmenter http.postBuffer est utile

Signé par : brian m. carlson

Les utilisateurs se retrouvent dans des situations très diverses avec des problèmes de push HTTP.

Souvent, ces problèmes sont dus à des logiciels antivirus, à des proxys de filtrage ou à d'autres situations de type "man-in-the-middle" ; d'autres fois, ils sont dus à un simple manque de fiabilité du réseau.

Cependant, une solution courante aux problèmes de poussée HTTP trouvée en ligne consiste à augmenter http.postBuffer.

Cela ne fonctionne dans aucune des situations susmentionnées et n'est utile que dans un petit nombre de cas très restreints : essentiellement, lorsque la connexion ne prend pas correctement en charge HTTP/1.1.

Documentez quand l'augmentation de cette valeur est appropriée et ce qu'elle fait réellement, et découragez les gens de l'utiliser comme une solution générale pour les problèmes de poussée, car elle n'est pas efficace dans ce cas.

Donc la documentation pour git config http.postBuffer comprend maintenant :

http.postBuffer

Taille maximale en octets du tampon utilisé par les transports HTTP intelligents lors du POST de données vers le système distant.
Pour les requêtes supérieures à cette taille de tampon, HTTP/1.1 et Transfer-Encoding : chunked sont utilisés pour éviter de créer localement un fichier pack massif.
La valeur par défaut est de 1 MiB, ce qui est suffisant pour la plupart des demandes.

Notez que l'augmentation de cette limite n'est efficace que pour désactiver l'encodage des transferts par morceaux et ne doit donc être utilisée que lorsque le serveur distant ou un proxy ne prend en charge que HTTP/1.0 ou n'est pas conforme à la norme HTTP.
Augmenter cette valeur n'est pas, en général, une solution efficace pour la plupart des problèmes de poussée, mais peut augmenter la consommation de mémoire de manière significative puisque le tampon entier est alloué même pour les petites poussées. .

Answer 2

L'astuce http.postBuffer a fait no travailler pour moi. Cependant :

Pour les autres personnes rencontrant ce problème, il peut s'agir d'un problème avec GnuTLS. Si vous activez le mode Verbose, vous pouvez voir l'erreur sous-jacente ressembler à quelque chose comme le code ci-dessous.

Malheureusement, ma seule solution à ce jour est d'utiliser SSH.

J'ai vu une solution affichée ailleurs pour compiler Git avec OpenSSL au lieu de GnuTLS. Il existe un rapport de bogue actif pour ce problème aquí .

GIT_CURL_VERBOSE=1 git clone https://github.com/django/django.git

Cloning into 'django'...
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * Connected to github.com (192.30.252.131) port 443 (#0)
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> GET /django/django.git/info/refs?service=git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept: */*
Accept-Encoding: gzip

Pragma: no-cache
< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:14 GMT

< Content-Type: application/x-git-upload-pack-advertisement
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
* Connection #0 to host github.com left intact
* Couldn't find host github.com in the .netrc file; using defaults
* About to connect() to github.com port 443 (#0)
*   Trying 192.30.252.131... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* SSL re-using session ID
*    server certificate verification OK
*    common name: github.com (matched)
*    server certificate expiration date OK
*    server certificate activation date OK
*    certificate public key: RSA
*    certificate version: #3
*    subject: 
*    start date: Mon, 10 Jun 2013 00:00:00 GMT
*    expire date: Wed, 02 Sep 2015 12:00:00 GMT
*    issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert High Assurance EV CA-1
*    compression: NULL
*    cipher: ARCFOUR-128
*    MAC: SHA1
> POST /django/django.git/git-upload-pack HTTP/1.1
User-Agent: git/1.8.4
Host: github.com
Accept-Encoding: gzip

Content-Type: application/x-git-upload-pack-request
Accept: application/x-git-upload-pack-result
Content-Encoding: gzip
Content-Length: 2299
* upload completely sent off: 2299out of 2299 bytes

< HTTP/1.1 200 OK
< Server: GitHub.com
< Date: Thu, 10 Oct 2013 03:28:15 GMT

< Content-Type: application/x-git-upload-pack-result
< Transfer-Encoding: chunked
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Vary: Accept-Encoding
< 
remote: Counting objects: 232015, done.
remote: Compressing objects: 100% (65437/65437), done.
* GnuTLS recv error (-9): A TLS packet with unexpected length was received.
* Closing connection #0
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Answer 3

Obs. : Changer http.postBuffer Il peut également être nécessaire de configurer le fichier de configuration Nginx pour gitlab afin d'accepter des tailles de corps plus importantes pour le client, en réglant la valeur de client_max_body_size.

Cependant, il existe une solution de contournement si vous avez accès à la machine Gitlab. ou à une machine de son réseau, et ce en faisant usage de git bundle .

1. allez dans votre dépôt git sur la machine source
2. ejecute git bundle create my-repo.bundle --all
3. transférer (par exemple, avec rsync) le fichier my-repo.bundle vers la machine de destination
4. sur la machine de destination, exécutez git clone my-repo.bundle
5. git remote set-url origin "path/to/your/repo.git"
6. git push

Bonne chance !

Answer 4

J'ai eu un problème similaire, mais avec un travail en bambou. Bamboo n'a pas réussi à faire un clone local (local mais via un proxy SSH) d'un dépôt en cache, j'ai supprimé le cache et après cela, ça a marché, mais chaque fois qu'il essaie de cloner à partir du cache local, il y a un échec. Il semble qu'il s'agisse d'un problème avec la version de bamboo du proxy SSH et non avec git en lui-même.

Answer 5

Il peut s'agir d'un simple problème de serveur. Si vous utilisez GitHub, vérifiez https://twitter.com/githubstatus . Je l'ai vu pour la première fois à l'instant et j'ai découvert GitHub a du mal à tenir le coup . Quelques minutes plus tard, il fonctionnait à nouveau parfaitement.