El extremo remoto se colgó inesperadamente mientras clonaba git

Resuelto Joe asked hace 13 años • 43 respuestas

Mi gitcliente falla repetidamente con el siguiente error después de intentar clonar el repositorio durante algún tiempo.

¿Cuál podría ser el problema aquí?

Nota: He registrado mi clave SSH con el proveedor de alojamiento GIT

Receiving objects:  13% (1309/10065), 796.00 KiB | 6 KiB/s
fatal: The remote end hung up unexpectedly
Joe avatar Jul 27 '11 17:07 Joe
Aceptado

Solución rápida:

Con este tipo de error, normalmente empiezo aumentando el postBuffertamaño de la siguiente manera:

git config --global http.postBuffer 524288000

(algunos comentarios a continuación informan que se debe duplicar el valor):

git config --global http.postBuffer 1048576000

(Para npm publish, Martin Braun informa en los comentarios que lo establece en no más de 50 000 000 en lugar del valor predeterminado 1 000 000)

Más información:

Desde la git configpágina de manual , http.postBufferse trata de:

Tamaño máximo en bytes del búfer utilizado por los transportes HTTP inteligentes al publicar datos en el sistema remoto.
Para solicitudes mayores que este tamaño de búfer, se utiliza HTTP/1.1 Transfer-Encoding: chunkedpara evitar la creación de un archivo de paquete masivo localmente. El valor predeterminado es 1 MiB, que es suficiente para la mayoría de las solicitudes.

Incluso para el clon, eso puede tener un efecto, y en este caso, el OP Joe informa:

[clon] funciona bien ahora

Nota: si algo salió mal en el lado del servidor y si el servidor usa Git 2.5+ (segundo trimestre de 2015), el mensaje de error podría ser más explícito.
Consulte " Clonación de Git: el extremo remoto se colgó inesperadamente, se intentó cambiar postBufferpero aún falla ".

Kulai ( en los comentarios ) señala esta página de Git de solución de problemas de Atlassian , que agrega:

Error code 56indica un error de recepción curl, CURLE_RECV_ERRORlo que significa que hubo algún problema que impidió que se recibieran los datos durante el proceso de clonación.
Normalmente, esto se debe a una configuración de red, un firewall, un cliente VPN o un antivirus que finaliza la conexión antes de que se hayan transferido todos los datos.

También menciona la siguiente variable de entorno, para ayudar con el proceso de depuración.

# 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

Con Git 2.25.1 (febrero de 2020), sabrás más sobre esta http.postBuffer"solución".

Consulte el compromiso 7a2dc95 y el compromiso 1b13e90 (22 de enero de 2020) de brian m. carlson ( bk2204) .
(Fusionado por Junio ​​C Hamano -- gitster-- en la confirmación 53a8329 , 30 de enero de 2020)
( Discusión sobre la lista de correo de Git )

docs: mencionar cuando aumentar http.postBuffer es valioso

Firmado por: brian m. carlson

Los usuarios en una amplia variedad de situaciones se encuentran con problemas de envío de HTTP.

A menudo, estos problemas se deben al software antivirus, servidores proxy de filtrado u otras situaciones de intermediario; otras veces, se deben a la simple falta de confiabilidad de la red.

Sin embargo, una solución común a los problemas de inserción HTTP que se encuentran en línea es aumentar http.postBuffer.

Esto no funciona en ninguna de las situaciones antes mencionadas y sólo es útil en un número pequeño y muy restringido de casos: esencialmente, cuando la conexión no admite correctamente HTTP/1.1.

Documente cuándo es apropiado aumentar este valor y qué hace realmente, y disuada a las personas de usarlo como una solución general para problemas de empuje, ya que no es efectivo allí.

Entonces la documentación por git config http.postBufferahora incluye:

http.postBuffer

Tamaño máximo en bytes del búfer utilizado por los transportes HTTP inteligentes al publicar datos en el sistema remoto.
Para solicitudes mayores que este tamaño de búfer, se utiliza HTTP/1.1 y Transfer-Encoding: fragmentado para evitar la creación de un archivo de paquete masivo localmente.
El valor predeterminado es 1 MiB, que es suficiente para la mayoría de las solicitudes.

Tenga en cuenta que aumentar este límite solo es efectivo para deshabilitar la codificación de transferencia fragmentada y, por lo tanto, debe usarse solo cuando el servidor remoto o un proxy solo admite HTTP/1.0 o no cumple con el estándar HTTP.
Aumentar esto no es, en general, una solución eficaz para la mayoría de los problemas de inserción, pero puede aumentar significativamente el consumo de memoria, ya que todo el búfer se asigna incluso para pequeñas inserción .

VonC avatar Jul 27 '2011 18:07 VonC

Mismo error con Bitbucket. Arreglado por

git config --global http.postBuffer 500M
git config --global http.maxRequestBuffer 100M
git config --global core.compression 0
wizawu avatar Jul 15 '2017 10:07 wizawu

El truco http.postBuffer no me funcionó. Sin embargo:

Para otras personas que experimenten este problema, puede ser un problema con GnuTLS. Si configura el modo detallado, es posible que vea que el error subyacente se parece a lo que se muestra en el código siguiente.

Desafortunadamente, mi única solución hasta ahora es usar SSH.

He visto una solución publicada en otro lugar para compilar Git con OpenSSL en lugar de GnuTLS. Hay un informe de error activo para el problema 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
Kurtis avatar Oct 10 '2013 03:10 Kurtis

Según esta respuesta , intenté seguir (con la URL https):

  1. clonación inicial del repositorio:

git clone --depth 25 url-here

  1. buscar confirmaciones con un aumento del doble por profundidad de intento:

git fetch --depth 50

git fetch --depth 100

git fetch --depth 200

...etcétera

  1. eventualmente (cuando creo que ya se ha recuperado lo suficiente) corro git fetch --unshallowy listo.

El proceso obviamente lleva mucho más tiempo, pero en mi caso http.postBufferno core.compressionayudó.

UPD : Descubrí que la recuperación a través de ssh funciona para cualquier tamaño de repositorio (descubierto accidentalmente), hecho con git clone <ssh url>, dado que ha creado claves ssh. Una vez que se recupera el repositorio, cambio la dirección remota usandogit remote set-url <https url to repo>

Андрей Саяпин avatar Jun 24 '2019 15:06 Андрей Саяпин