fatal: EOF precoz fatal: el package de índice falló

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

Estoy tratando de clonar desde una máquina conectándome al server remoto que está en la networking LAN.
Ejecutar este command desde otra máquina causa un error.
Pero ejecutar el command SAME clone usando git: //192.168.8.5 … en el server 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 configuration en .gitconfig pero tampoco ayuda.
Usando la versión de Git 1.8.5.2.msysgit.0

 [core] compression = -1 

Primero, apague la compression:

 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 directory y recupere el rest 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).

Este error puede ocurrir por las necesidades de memory de git. Puede agregar estas líneas a su file de configuration 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 

Obtuve este error cuando git se quedó sin memory.

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

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

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

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

si es el command clonar:

 git clone <your_http_or_https_repo_url> 

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

 git remote set-url origin <your_http_or_https_repo_url> 

Espero que esto ayude a alguien!

En mi caso esto fue bastante útil:

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

Esto limitará el pago solo a la twig mencionada, por lo tanto, acelerará el process.

Espero que esto ayude

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

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

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 twig específica. Esto me ayudó:

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

Ninguno de estos funcionó para mí, pero usar la herramienta incorporada de Heroku hizo el truco.

 heroku git:clone -a myapp 

Documentación aquí: https://devcenter.heroku.com/articles/git-clone-heroku-app

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.

Tenga en count que Git 2.13.x / 2.14 (Q3 2017) aumenta el core.packedGitLimit pnetworkingeterminado que influye en la git fetch :
El valor límite del package pnetworkingeterminado pnetworkingeterminado se ha elevado en plataforms más grandes ( de 8 GiB a 32 GiB ) para save " 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á packages.
Si hay una operación de reempaquetado en paralelo con una recuperación, la extracción podría abrir un package, y luego ser forzado a cerrarlo debido a que se golpeó el GetGitLimit.
El reempaquetado podría eliminar el package de debajo de la búsqueda, lo que provocaría que la recuperación fallara.

Aumente el valor pnetworkingeterminado 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 repository de git estará cerca de este tamaño en el corto ploop, así que esto debería evitar la falla.

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

Básicamente, después de ejecutar el git.exe daemon ... , select un text de esa window de la console. ¡Reintentar tirar / clonar, podría funcionar ahora!

Vea esta respuesta para más información.

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

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

I: \ dev [maestro +0 ~ 6 -0]> git fetch –unshallow remote: Contando objects: 645483, hecho. remoto: Comprimir objects: 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 package de índice falló

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

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