fatal: EOF temprano fatal: falló el paquete de índice

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

Estoy intentando 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 mismo comando de clonación 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 .gitconfigpero tampoco ayuda.
Usando la versión git 1.8.5.2.msysgit.0

[core]
    compression = -1

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 se reduce:

git clone --depth 1 <repo_URI>

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

git fetch --unshallow 

o, alternativamente,

git fetch --depth=2147483647

Ahora, haz un tirón regular:

git pull --all

Creo que hay un error 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 para las necesidades de memoria de git. Puede agregar estas líneas a su archivo de configuración global de git, que está .gitconfigen $USER_HOME, para solucionar ese problema.

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

finalmente resuelto por git config --global core.compression 9

De un hilo de problema de BitBucket:

Lo intenté casi cinco veces, y todavía sucede.

Luego intenté usar una mejor compresión y funcionó.

git config --global core.compression 9

De la documentación de Git:

core.compression
Un entero -1..9, que indica un nivel de compresión predeterminado. -1 es el valor predeterminado de zlib.
0 significa que no hay compresión, y 1..9 son varias compensaciones de velocidad / tamaño, siendo 9 el más lento.
Si se establece, esto proporciona un valor predeterminado para otras variables de compresión, como core.looseCompression y pack.compression.

Como @ingyhere dijo:

Clon superficial

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 se reduce:

git clone --depth 1 <repo_URI>

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

git fetch --unshallow

o, alternativamente,

git fetch --depth=2147483647

Ahora, haz un tirón:

git pull --all

Luego, para resolver el problema de su sucursal local solo maestro de seguimiento

abra su archivo de configuración de git ( .git/config) en el editor de su elección

En donde dice:

[remote "origin"]
    url=<git repo url>
    fetch = +refs/heads/master:refs/remotes/origin/master

cambiar la linea

fetch = +refs/heads/master:refs/remotes/origin/master

a

fetch = +refs/heads/*:refs/remotes/origin/*

Haga una búsqueda de git y git extraerá todas sus ramas remotas ahora

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.

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

si es el comando clone do:

git clone <your_http_or_https_repo_url> 

de lo contrario, si está utilizando un repositorio existente, hágalo con

git remote set-url origin <your_http_or_https_repo_url>

Espero que esto ayude a alguien!

Recibí este error cuando git se quedó sin memoria.

Liberar algo de memoria (en este caso: dejar que termine un trabajo de compilación) y volver a intentarlo funcionó para mí.

En mi caso fue un problema de conexión. Estaba conectado a una red wifi interna, en la que tenía acceso limitado a recursos. Eso estaba dejando 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.

Por lo tanto, la respuesta de elin3t es importante porque ssh mejora el rendimiento de la descarga para evitar problemas de red.

Establecer la configuración de abajo no funciona para mí.

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

Como comentario anterior, podría ser el problema de memoria de git. Por lo tanto, trato de reducir los hilos de trabajo (de 32 a 8). Para que no obtenga muchos datos del servidor al mismo tiempo. Luego también agrego "-f" para forzar la sincronización de otros proyectos.

-f: Proceed with syncing other projects even if a project fails to sync.

Entonces funciona bien ahora.

repo sync -f -j8

Una respuesta anterior recomienda configurar a 512m. Diría que hay razones para pensar que es contraproducente en una arquitectura de 64 bits. La documentación para core.packedGitLimit dice:

El valor predeterminado es 256 MiB en plataformas de 32 bits y 32 TiB (efectivamente ilimitado) en plataformas de 64 bits. Esto debería ser razonable para todos los usuarios / sistemas operativos, excepto en los proyectos más grandes. Probablemente no necesite ajustar este valor.

Si desea probarlo, verifique si lo tiene configurado y luego elimine la configuración:

git config --show-origin core.packedGitLimit
git config --unset --global core.packedGitLimit

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

Ver commit be4ca29 (20 abr 2017) por David Turner ( csusbdt) .
Ayudado por: Jeff King ( peff) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit d97141b , 16 de mayo de 2017)}

Incrementar core.packedGitLimit

Cuando core.packedGitLimitse excede, git cerrará los paquetes.
Si hay una operación de reempaquetado en paralelo con una recuperación, la recuperación puede abrir un paquete y luego verse obligado a cerrarlo debido a que se ha alcanzado el paquete GitLimit.
El reempaque podría eliminar el paquete de debajo de la recuperación, lo que provocaría que la recuperación fallara.

Aumente core.packedGitLimitel valor predeterminado para evitar esto.

En las máquinas actuales de 64 bits x86_64, hay 48 bits de espacio de direcciones disponibles.
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 que razonablemente nos puede interesar. 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 git estará cerca de este tamaño en cualquier momento pronto, por lo que esto debería evitar la falla.

Usando la respuesta @cmpickle, construí un script para simplificar el proceso de clonación.

Está alojado aquí: https://gist.github.com/gianlucaparadise/10286e0b1c5409bd1049d67640fb7c03

Puede ejecutarlo usando la siguiente línea:

curl -sL https://git.io/JvtZ5 | sh -s repo_uri repo_folder

En mi caso, el problema no era ninguno de los parámetros de configuración de git sino el hecho de que mi repositorio tenía un archivo que excedía el tamaño máximo permitido en mi sistema. Pude comprobarlo intentando descargar un archivo grande y obteniendo un "Límite de tamaño de archivo excedido" en Debian.

Después de eso edité mi archivo /etc/security/limits.conf agregando y al final las siguientes líneas: * hard fsize 1000000 * soft fsize 1000000

Para realmente "aplicar" los nuevos valores límite, debe volver a iniciar sesión

Tangencialmente relacionado y solo útil en caso de que no tenga acceso a la raíz y extraiga manualmente Git de un RPM (con rpm2cpio) u otro paquete (.deb, ..) en una subcarpeta. Caso de uso típico: intenta utilizar una versión más nueva de Git sobre la obsoleta en un servidor corporativo.

Si falla el clon de git fatal: index-pack failed sin una mención inicial de EOF, sino un mensaje de ayuda usage: git index-pack, hay una discrepancia de versión y debe ejecutar git con el --exec-pathparámetro:

git --exec-path=path/to/subfoldered/git/usr/bin/git clone <repo>

Para que esto suceda automáticamente, especifique en su ~/.bashrc:

export GIT_EXEC_PATH=path/to/subfoldered/git/usr/libexec

Tuve los mismos registros de error, usando git (v2.17.1) sobre ssh. En mi caso la solución es:

1. Ingrese al repositorio git bare de mi servidor.
2. Llamar git gc.

Consulte la documentación de git-gc: https://git-scm.com/docs/git-gc .

P.ej:

ssh admin@my_server_url.com
sudo su git
cd /home/git/my_repo_name # where my server's bare repository exists.
git gc

Ahora puedo clonar este repositorio sin errores, por ejemplo, en el lado del cliente:

git clone git@my_server_url.com:my_repo_name

El comando git gcpuede ayudar llamado en el lado del cliente git para evitar un git pushproblema similar .

Otra solución (pirateo) es descargar el último maestro sin historial:

git clone --single-branch --depth=1 git@my_server_url.com:my_repo_name

Existe la posibilidad de que no se produzca un desbordamiento del búfer.

En mi caso, nada funcionó cuando el protocolo era https, luego cambié a ssh y me aseguré de sacar el repositorio de la última confirmación y no toda la historia, y también una rama específica. Esto me ayudó:

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

Mientras tanto, apagué todas las descargas que estaba haciendo, lo que probablemente liberó algo 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, la solución de seleccionar texto en la consola para "bloquear el búfer de salida" ya no debería ser necesaria.

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

• Varias correcciones para "git daemon". (Fusionar ed15e58efe jk / daemon-fixes luego para mantener).

Tengo el mismo problema. Siguiendo el primer paso anterior pude clonar, pero no puedo hacer nada más. No se pueden recuperar, extraer o retirar ramas viejas.

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

I:\dev [master +0 ~6 -0]> git fetch --unshallow
remote: Counting objects: 645483, done.
remote: Compressing objects: 100% (136865/136865), done.

error: RPC failed; result=18, HTTP code = 20082 MiB | 6.26 MiB/s

fatal: early EOF

fatal: The remote end hung up unexpectedly

fatal: index-pack failed

Esto también sucede cuando tus árbitros están usando demasiada memoria. Podar la memoria me arregló esto. Simplemente agregue un límite a lo que busca así ->

git fetch --depth=100

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

Intenté la mayoría de las respuestas aquí, recibí el error con el cliente PUTTY SSH con todas las constelaciones posibles.

Una vez que cambié a OpenSSH, el error desapareció (elimine la variable de entorno GIT_SSH y reinicie git bash).

Estaba usando una máquina nueva y las versiones más nuevas de git. En muchas otras máquinas / antiguas (también AWS) funcionó como se esperaba con PUTTY también sin ninguna configuración de git.

He experimentado el mismo problema. El REPO era demasiado grande para ser descargado a través de SSH. Al igual que @ elin3t recomienda, he clonado sobre HTTP / HTTPS y cambio la URL REMOTA en .git / config para usar el SSH REPO.

Tengo el mismo problema que a continuación cuando ejecuto git pull

remote: Counting objects: 149, done.
Connection to git-codecommit.us-east-1.amazonaws.com closed by remote host.
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

Luego verifiqué git status, Hubo tantos cambios no confirmados que arreglé el problema al confirmar y presionar todos los cambios no confirmados.

Ninguna de las soluciones anteriores funcionó para mí.

La solución que finalmente funcionó para mí fue cambiar el cliente SSH. La variable de entorno GIT_SSH se configuró en OpenSSH proporcionado por Windows Server 2019. Versión 7.7.2.1

C:\Windows\System32\OpenSSH\ssh.exe

Simplemente instalé masilla, 0.72

choco install putty

Y cambió GIT_SSH a

C:\ProgramData\chocolatey\lib\putty.portable\tools\PLINK.EXE

Intenté casi todas las sugerencias hechas aquí, pero ninguna funcionó. Para nosotros, el problema era temperamental y empeoraba cada vez más a medida que los repositorios se volvían más grandes (en nuestro esclavo de compilación Jenkins Windows).

Terminó siendo la versión de ssh utilizada por git. Git se configuró para usar alguna versión de Open SSH, especificada en el archivo .gitconfig de los usuarios a través de la variable core.sshCommand. Quitar esa línea lo arregló. Creo que esto se debe a que Windows ahora viene con una versión más confiable / compatible de SSH que se usa por defecto.

Esto funcionó para mí, 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

De un clon de 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 repositorio bien.

Si está en Windows, ¿es posible que desee comprobar que git clone falla con "index-pack"? .

Básicamente, después de ejecutar su git.exe daemon ...comando, seleccione un texto de la ventana de esa consola. Vuelva a intentar la extracción / clonación, ¡podría funcionar ahora!

Vea esta respuesta para más información.

Asegúrese de que a su unidad le quede suficiente espacio

Ninguno de estos funcionó para mí, pero el uso de la herramienta integrada de Heroku funcionó.

heroku git:clone -a myapp

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