with unexpectedly the tag remote index fatal failed error end early code bad git cygwin msysgit

git - tag - the remote end hung up unexpectedly bitbucket



fatal: EOF precoz fatal: el paquete de índice falló (17)

Busqué en Google y encontré muchas soluciones, pero ninguna me funciona.

Estoy tratando de clonar desde una máquina conectándome al servidor remoto que está en la red LAN.
Ejecutar este comando desde otra máquina causa un error.
Pero ejecutar el comando SAME clone usando git: //192.168.8.5 ... en el servidor está bien y es exitoso.

Algunas ideas ?

user@USER ~ $ git clone -v git://192.168.8.5/butterfly025.git Cloning into ''butterfly025''... remote: Counting objects: 4846, done. remote: Compressing objects: 100% (3256/3256), done. fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s fatal: early EOF fatal: index-pack failed

He agregado esta configuración en .gitconfig pero tampoco ayuda.
Usando la versión de Git 1.8.5.2.msysgit.0

[core] compression = -1

Asegúrate de que tu disco tenga suficiente espacio libre

De un clon git, estaba obteniendo:

error: inflate: data stream error (unknown compression method) fatal: serious inflate inconsistency fatal: index-pack failed

Después de reiniciar mi máquina, pude clonar el repo fine.

Desactivé todas las descargas que estaba haciendo mientras tanto, lo que liberó un poco de espacio y eliminé el ancho de banda

El problema de git-daemon parece haberse resuelto en v2.17.0 (verificado con un v2.16.2.1 que no funciona). Es decir, ya no se necesita una solución alternativa para seleccionar texto en la consola para "bloquear el buffer de salida".

Desde https://github.com/git/git/blob/v2.17.0/Documentation/RelNotes/2.17.0.txt :

  • Correcciones variadas para "git daemon". (fusionar ed15e58efe jk / daemon-fixes más tarde para maint).

En mi caso esto fue bastante útil:

git clone --depth 1 --branch $BRANCH $URL

Esto limitará el pago solo a la rama mencionada, por lo tanto, acelerará el proceso.

Espero que esto ayude

En mi caso, fue un problema de conexión. Estaba conectado a una red wifi interna, en la que tenía acceso limitado a los recursos. Eso fue dejar que Git hiciera la búsqueda, pero en un momento dado se estrelló. Esto significa que puede ser un problema de conexión de red. Compruebe si todo funciona correctamente: Antivirus, Firewall, etc.

La respuesta de elin3t es por lo tanto importante porque ssh mejora el rendimiento de la descarga para que los problemas de red puedan evitarse

En mi caso, nada funcionó cuando el protocolo era https, luego cambié a ssh y me aseguré de sacar el repo del último compromiso y no todo el historial, y también una rama específica. Esto me ayudó:

git clone --depth 1 "ssh: .git" --branch "specific_branch"

Este error puede ocurrir por las necesidades de memoria de git. Puede agregar estas líneas a su archivo de configuración global de git, que es .gitconfig en $USER_HOME , para solucionar ese problema.

[core] packedGitLimit = 512m packedGitWindowSize = 512m [pack] deltaCacheSize = 2047m packSizeLimit = 2047m windowMemory = 2047m

Esto funcionó para mí, configurando el servidor de nombres de Google porque no se especificó un servidor de nombres estándar, seguido por el reinicio de la red:

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

Intenté todos esos comandos y ninguno funciona para mí, pero lo que sí funciona fue cambiar el git_url por http en lugar de ssh

si es el comando clonar:

git clone <your_http_or_https_repo_url>

de lo contrario, si está tirando del repositorio existente, hágalo con

git remote set-url origin <your_http_or_https_repo_url>

Espero que esto ayude a alguien!

Obtuve este error cuando git se quedó sin memoria.

Liberar algo de memoria (en este caso, dejar que termine un trabajo de compilación) e intentar de nuevo funcionó para mí.

Primero, apague la compresión:

git config --global core.compression 0

A continuación, hagamos un clon parcial para truncar la cantidad de información que baja:

git clone --depth 1 <repo_URI>

Cuando eso funcione, ingrese al nuevo directorio y recupere el resto del clon:

git fetch --unshallow

o, alternativamente,

git fetch --depth=2147483647

Ahora, haz una extracción regular:

git pull --all

Creo que hay un problema con msysgit en las versiones 1.8.x que exacerba estos síntomas, por lo que otra opción es probar con una versión anterior de git (<= 1.8.3, creo).

Si está en Windows, es posible que desee comprobar que git clone falla con el "paquete de índice" ¿falló? .

Básicamente, después de ejecutar el git.exe daemon ... , seleccione un texto de esa ventana de la consola. ¡Reintentar tirar / clonar, podría funcionar ahora!

Vea esta respuesta para más información.

Tenga en cuenta que Git 2.13.x / 2.14 (Q3 2017) aumenta el core.packedGitLimit predeterminado que influye en la git fetch :
El valor límite del paquete predeterminado predeterminado se ha elevado en plataformas más grandes ( de 8 GiB a 32 GiB ) para guardar " git fetch " de una falla (recuperable) mientras " gc " se ejecuta en paralelo.

Ver commit be4ca29 (20 de abril de 2017) por David Turner ( csusbdt ) .
Ayudado por: Jeff King ( peff ) .
(Fusionado por Junio ​​C Hamano - gitster - in commit d97141b , 16 de mayo de 2017)

Aumenta core.packedGitLimit

Cuando core.packedGitLimit , git cerrará paquetes.
Si hay una operación de reempaquetado en paralelo con una captura, la extracción podría abrir un paquete, y luego ser forzado a cerrarlo debido a que se golpeó el GetGitLimit.
El reempaquetado podría eliminar el paquete de debajo de la búsqueda, lo que provocaría que la recuperación fallara.

Aumente el valor predeterminado de core.packedGitLimit para evitar esto.

En las máquinas actuales de 64 bits x86_64, hay disponibles 48 bits de espacio de direcciones.
Parece que las máquinas ARM de 64 bits no tienen una cantidad estándar de espacio de direcciones (es decir, varía según el fabricante), y las máquinas IA64 y POWER tienen los 64 bits completos.
Entonces, 48 ​​bits es el único límite del que podemos preocuparnos razonablemente. Reservamos algunos bits del espacio de direcciones de 48 bits para el uso del kernel (esto no es estrictamente necesario, pero es mejor estar seguro), y utilizamos hasta los 45 restantes.
Ningún repositorio de git estará cerca de este tamaño en el corto plazo, así que esto debería evitar la falla.

Tengo el mismo problema. Siguiendo el primer paso anterior pude clonar, pero no puedo hacer nada más. No se puede buscar, tirar o sacar viejas ramas.

Cada comando se ejecuta mucho más lento de lo habitual, luego muere después de comprimir los objetos.

I: / dev [maestro +0 ~ 6 -0]> git fetch --unshallow remote: Contando objetos: 645483, hecho. remoto: Comprimir objetos: 100% (136865/136865), hecho.

error: RPC falló; resultado = 18, código HTTP = 20082 MiB | 6.26 MiB / s

fatal: primeros EOF

fatal: el extremo remoto colgó inesperadamente

fatal: el paquete de índice falló

Esto también ocurre cuando tus ref utilizan demasiada memoria. Podar la memoria solucionó esto por mí. Simplemente agregue un límite a lo que está buscando, entonces -> git fetch --depth = 100

Esto buscará los archivos pero con las últimas 100 ediciones en sus historias. Después de esto, puedes hacer cualquier comando bien y a velocidad normal.