restaurar remota recuperar rama manejo crear como cambiar git

remota - El extremo remoto colgó inesperadamente mientras la clonación de git



manejo de git (26)

Mi cliente git falla repetidamente con el siguiente error después de intentar clonar el repositorio por algún tiempo.

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

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

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

Solución rápida:

Con este tipo de error, generalmente comienzo elevando el tamaño de postBuffer en:

git config --global http.postBuffer 524288000

(Algunos comentarios a continuación reportan tener que duplicar el valor):

git config --global http.postBuffer 1048576000

Más información:

Desde la página de http.postBuffer git config , http.postBuffer se trata de:

Tamaño máximo en bytes del búfer utilizado por los transportes HTTP inteligentes al enviar datos al sistema remoto.
Para solicitudes más grandes que este tamaño de búfer, HTTP / 1.1 y Transfer-Encoding: chunked se utilizan para evitar la creación de un archivo de paquete masivo de forma local. 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 informa:

[clon] funciona bien ahora

Nota: si algo salió mal en el lado del servidor, y si el servidor usa Git 2.5+ (Q2 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 postBuffer pero sigue fallando ".

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

Error code 56 indica un error de CURLE_RECV_ERROR de CURLE_RECV_ERROR de CURLE_RECV_ERROR que significa que hubo algún problema que impidió que los datos se recibieran durante el proceso de clonación.
Por lo general, 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 transfieran 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

Bueno, quería empujar una solución de 219 MB, pero no tuve suerte con

git config --global http.postBuffer 524288000

¿Y cuál es el punto de tener un búfer de 525 MB de todos modos? es tonto Así que miré el error de git a continuación:

Total 993 (delta 230), reused 0 (delta 0) POST git-receive-pack (5173245 bytes) error: fatal: RPC failed; curl 56 SSL read: error:00000000:lib(0):func(0):reason(0), errno 10054

Así que git quiere publicar 5 MB, luego hice el búfer de publicación 6 MB, y funciona

git config --global http.postBuffer 6291456

Compruebe su velocidad de internet. También puedes ver los siguientes comandos:

$ git config --global http.postBuffer 2M $ git pull origin master

Descubrí que mi problema estaba relacionado con el archivo .netrc, si es así para ti también puedes hacer lo siguiente:

Abra su archivo .netrc y edítelo para incluir las credenciales de github. Escriba nano ~/netrc o gedit ~/netrc

Luego incluye lo siguiente: * máquina github.com

nombre de usuario de inicio de sesión

contraseña secreta

máquina api.github.com

nombre de usuario de inicio de sesión

contraseña SECRETO *

Puede incluir su contraseña sin formato allí, pero por razones de seguridad, genere un token de autenticación aquí token de github y péguelo en lugar de su contraseña.

Espero que esto ayude a alguien

El truco http.postBuffer no funcionó para mí. Sin embargo:

Para otros que experimentan este problema, puede ser un problema con GnuTLS. Si configura el modo Verbose, es posible que vea el error subyacente como algo similar al código a continuación.

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

He visto una solución publicada en elsewhere para compilar Git con OpenSSL en lugar de GnuTLS. Hay un informe de error activo para el problema here .

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

Enfrentó el mismo problema, intente fusionarse con otra rama y obtener un impulso de ellos. Funciona para mí igual.

Estaba haciendo git push desde mi OS X El Capitan Mac. Recibí el mismo error, intenté todo para solucionarlo, lo que encontré en google / . En cuanto a la versión, estoy usando una versión bastante reciente de github, que es 2.7.4. He creado un proyecto en mi sistema local y quería que fuera público en mi cuenta de github. El tamaño del proyecto no rondaba los 8MB. Noté que cuando estaba empujando algunos archivos de tamaño alrededor de 1.5MB, estaba empujando correctamente, pero con un gran tamaño falló, con el mismo error,

La única opción que tenía era empujar los cambios en la porción de MB. Ahora he empujado todos los cambios. Esta es una solución para mí hasta que me arregle esta solución.

Por lo que también puede intentar empujar el cambio en la confirmación múltiple. O si tiene varias carpetas, puede empujar los cambios en cada carpeta (si el tamaño de la carpeta no es grande).

Espero que esto te ayude a seguir trabajando en el proyecto.

Esto me funcionó, configurando el servidor de nombres de Google porque no se especificó ningún servidor de nombres estándar, seguido de reiniciar la red:

sudo echo "dns-nameservers 8.8.8.8" >> /etc/network/interfaces && sudo ifdown venet0:0 && sudo ifup venet0:0

Esto se debe al problema de conectividad a Internet, me enfrenté al mismo problema. Hice una copia superficial de código usando

git clone --depth 1 //FORKLOCATION

Más tarde no se muestra el clon usando

git fetch --unshallow

Lo único que me funcionó fue clonar el repositorio mediante el enlace HTTPS en lugar del enlace SSH .

Me enfrenté a este problema usando git en Kubuntu. También noté una inestabilidad general en las redes y encontré una solution .

en /etc/resolv.conf agregue la línea al final del archivo

opciones de solicitud única

Esto solucionó los retrasos antes de que cada resolución de nombre de dominio y git comenzaran a funcionar como un encanto después de esto.

Me enfrentaba a este problema cuando clonaba datos (a través de HTTP) desde un repositorio de git remoto alojado en una instancia de AWS EC2 administrada por elastic beanstalk. La clonación en sí también se realizó en la instancia de AWS EC2.

Probé todas las soluciones antes mencionadas y sus combinaciones:

  • configurando el http.postBuffer de git
  • configurando http.maxrequestbuffer
  • desactivar la compresión git y probar el git clone "superficial" y luego git fetch --unshallow - ver fatal: temprano EOF fatal: index-pack falló
  • ajuste de la configuración de la memoria GIT - packedGitLimit et al, ver aquí: fatal: temprano EOF fatal: paquete de índice fallado
  • ajuste de la configuración nginx: configuración de client_max_body_size a gran valor y 0 (ilimitado); configurando proxy_request_buffering off;
  • configurando options single-request en /etc/resolv.conf
  • la aceleración del rendimiento del cliente git con trickle
  • usando strace para rastrear el git clone
  • considerando actualizar el cliente git

Después de todo esto, todavía estaba enfrentando el mismo problema una y otra vez, hasta que encontré que el problema estaba en Elastic Load Balancer (ELB) cortando la conexión . Después de acceder a la instancia de EC2 (la que aloja el repositorio de git) directamente en lugar de ir a través de ELB, finalmente he logrado clonar el repositorio de git. Todavía no estoy seguro de cuál de los parámetros de ELB (timeout) es responsable de esto, por lo que todavía tengo que investigar un poco.

ACTUALIZAR

Parece que cambiar la política de Drenaje de la Conexión para AWS Elastic Load Balancer al aumentar el tiempo de espera de 20 segundos a 300 segundos resolvió este problema para nosotros.

La relación entre los errores del git clone y el "drenaje de la conexión" es extraña y no es obvia para nosotros. Es posible que el cambio de tiempo de espera de drenaje de la conexión causó algunos cambios internos en la configuración de ELB que solucionó el problema con el cierre prematuro de la conexión.

Esta es la pregunta relacionada en el foro de AWS (todavía no hay respuesta): https://forums.aws.amazon.com/thread.jspa?threadID=258572

Mismo error con Bitbucket. Arreglado por

git config --global http.postBuffer 524288000 git config --global http.maxRequestBuffer 100M git config --global core.compression 0

Nada de lo anterior funcionó para mí, pero esto es lo que hizo: https://.com/a/22317479

El mensaje de error completo que había estado recibiendo era:

fatal: The remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed

Obs .: El cambio de http.postBuffer también puede requerir configurar el archivo de configuración Nginx para que gitlab acepte tamaños de cuerpo más grandes para el cliente, al ajustar el valor de client_max_body_size.

Sin embargo, hay una solución alternativa si tiene acceso a la máquina Gitlab o a una máquina en su red, y es mediante el uso de git bundle .

  1. Ve a tu repositorio git en la máquina fuente
  2. ejecutar git bundle create my-repo.bundle --all
  3. transferir (por ejemplo, con rsync) el archivo my-repo.bundle a la máquina de destino
  4. en la máquina de destino, ejecute git clone my-repo.bundle
  5. git remote set-url origin "path/to/your/repo.git"
  6. git push

¡Todo lo mejor!

Puede deberse al tamaño de las confirmaciones que se están enviando. Desglose el número de confirmaciones mediante los siguientes pasos:

git log -5

Vea las últimas 5 confirmaciones y sabría cuáles no están puestas a distancia. Seleccione un ID de confirmación y presione todas las confirmaciones hasta ese ID:

git push <remote_name> <commit_id>:<branch_name>

NOTA: Acabo de verificar mi compromiso, que podría tener el tamaño más grande; Primero empujó hasta entonces. El truco funcionó. !!

SOLUCIONADO CON WIFI Router Configuración:

Tengo el mismo problema cuando estoy en wifi con Configuraciones PPPoE (inicio de sesión automático mediante un enrutador wifi).

La velocidad de descarga de Git es muy lenta 15kb.

packet_write_wait: conexión al 17.121.133.16 puerto 22: tubería rota fatal: el extremo remoto se cuelga de forma inesperada fatal: temprano EOF fatal: paquete de índice fallado

Solución: 1. Se cambió la configuración a Dynamic IP, reinicie el router wifi. 2. Desde el inicio de sesión del navegador web al portal del proveedor de servicios de Internet (no configure PPPoE, inicio de sesión automático desde el router wifi).

Después de cambiar la velocidad de descarga de Git es de 1.7MiB.

Si está utilizando https y está recibiendo el error.

Utilicé https en lugar de http y resolví mi problema

git config --global https.postBuffer 524288000

También tuve el mismo problema. La razón de este problema es la descripción de Kurtis sobre GNUTLS.

Si tiene el mismo motivo y su sistema es Ubuntu, puede resolver este problema instalando la última versión de git desde ppa:git-core/ppa . Los comandos son los siguientes.

sudo add-apt-repository ppa:git-core/ppa sudo apt-get update sudo apt-get git

Tengo el mismo error mientras uso BitBucket. Lo que hice fue eliminar https de la URL de mi repositorio y establecer la URL mediante HTTP .

git remote set-url origin http://[email protected]/mj/pt.git

Tengo el mismo problema, lo solucioné con el método de prueba y error. Cambié el valor de core.compression hasta que funcione.

Comencé con "git config --global core.compression 1" después de 3 intentos

"git config --global core.compression 4" funcionó para mí.

Tengo solución después de usar el siguiente comando:

git repack -a -f -d --window=250 --depth=250

Tuve el mismo problema y estaba relacionado con una mala conexión a Internet, así que después de intentar con algunas configuraciones de git, me desconecté de la red y me conecté nuevamente, ¡y funciona!

Parece que después de la conexión perdida (o la acción que dispara esta situación), git está atascado.

Espero que pueda ser de ayuda para alguien más aquí.

Mejor,

Tuve un problema similar, pero con un trabajo de bambú. Bamboo estaba fallando al hacer un clon local (local pero sobre un proxy SSH) de un repositorio en caché, borré el caché y después de eso funcionó, pero cada vez que intenta clonar desde el caché local, hay un error. Parece un problema con la versión de bambú del proxy SSH no git per se.

en /etc/resolv.conf agregue la línea al final del archivo

options single-request