fatal: early EOF fatal: index-pack failed

Eu pesquisei e encontrei muitas soluções, mas nenhuma funciona para mim.

Eu estou tentando clonar de uma máquina, conectando-se ao servidor remoto que está na rede LAN.
Executar este comando de outra máquina causa um erro.
Mas executar o comando SAME clone usando o git: //192.168.8.5 … no servidor está correto e bem-sucedido.

Alguma ideia ?

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 

Eu adicionei esta configuração no .gitconfig mas não ajuda também.
Usando a versão git 1.8.5.2.msysgit.0

 [core] compression = -1 

Primeiro, desative a compactação:

 git config --global core.compression 0 

Em seguida, vamos fazer um clone parcial para truncar a quantidade de informações que estão surgindo:

 git clone --depth 1  

Quando isso funcionar, entre no novo diretório e recupere o resto do clone:

 git fetch --unshallow 

ou, alternadamente,

 git fetch --depth=2147483647 

Agora, faça um puxão regular:

 git pull --all 

Eu acho que há uma falha com msysgit nas versões 1.8.x que exacerba esses sintomas, então outra opção é tentar com uma versão anterior do git (<= 1.8.3, eu acho).

Este erro pode ocorrer para as necessidades de memory do git. Você pode adicionar essas linhas ao seu arquivo de configuração git global, que é .gitconfig em $USER_HOME , para corrigir esse problema.

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

Eu recebi este erro quando o git ficou sem memory.

Liberar alguma memory (neste caso: deixar um trabalho de compilation terminar) e tentar novamente funcionou para mim.

Eu tentei todos os comandos e nenhum funciona para mim, mas o que funciona foi mudar o git_url para http em vez de ssh

se é o comando clone do:

 git clone  

mais se você está puxando em repo existente, faça isso com

 git remote set-url origin  

Espero que isso ajude alguém!

No meu caso, foi um problema de conexão. Eu estava conectado a uma rede wifi interna, na qual eu tinha access limitado a resources. Isso foi deixando git fazer a busca, mas em um determinado momento ele caiu. Isso significa que pode ser um problema de conexão de rede. Verifique se tudo está funcionando corretamente: antivírus, firewall, etc.

A resposta do elin3t é, portanto, importante porque o ssh melhora o desempenho do download para que os problemas de rede possam ser evitados.

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

https://bitbucket.org/site/master/issues/13290/connection-to-bitbucketorg-closed-by

No meu caso, isso foi bastante útil:

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

Isso limitará o check-out apenas ao ramo mencionado, acelerando o processo.

Espero que isso ajude.

No meu caso, nada funcionou quando o protocolo foi https, então mudei para o ssh, e assegurei, puxei o repo do último commit e não o histórico inteiro, e também o branch específico. Isso me ajudou:

git clone –depth 1 “ssh: .git” –branch “specific_branch”

Certifique-se de que sua unidade tenha espaço suficiente

Note que o Git 2.13.x / 2.14 (Q3 2017) aumenta o padrão core.packedGitLimit que influencia o git fetch :
O valor-limite do pacote-padrão padrão foi aumentado em plataformas maiores ( de 8 GiB para 32 GiB ) para salvar ” git fetch ” de uma falha (recuperável) enquanto o ” gc ” está sendo executado em paralelo.

Veja commit be4ca29 (20 de abril de 2017) por David Turner ( csusbdt ) .
Ajudado por: Jeff King ( peff ) .
(Mesclado por Junio ​​C Hamano – gitster – em commit d97141b , 16 de maio de 2017)

Aumentar core.packedGitLimit

Quando o core.packedGitLimit é excedido, o git fechará os pacotes.
Se houver uma operação de reempacotamento acontecendo paralelamente a uma busca, a busca poderá abrir um pacote e ser forçada a fechá-lo, pois o packedGitLimit será atingido.
O pacote pode então excluir o pacote da busca, fazendo com que a busca falhe.

Aumente o valor padrão do core.packedGitLimit para evitar isso.

Nas máquinas x86_64 de 64 bits atuais, estão disponíveis 48 bits de espaço de endereço.
Parece que as máquinas ARM de 64 bits não possuem uma quantidade padrão de espaço de endereço (isto é, varia de acordo com o fabricante) e as máquinas IA64 e POWER têm 64 bits completos.
Então, 48 bits é o único limite com o qual podemos nos preocupar razoavelmente. Reservamos alguns bits do espaço de endereços de 48 bits para o uso do kernel (isso não é estritamente necessário, mas é melhor estar seguro) e usamos até os 45 restantes.
Nenhum repository git estará em qualquer lugar próximo deste tamanho tão cedo, então isso deve evitar a falha.

Eu tenho o mesmo problema. Após o primeiro passo acima, consegui clonar, mas não posso fazer mais nada. Não é possível buscar, puxar ou verificar as ramificações antigas.

Cada comando é executado muito mais devagar que o normal, depois morre depois de compactar os objects.

I: \ dev [mestre +0 ~ 6 -0]> git fetch –unshallow remote: Contando objects: 645483, pronto. remote: Compactando objects: 100% (136865/136865), pronto.

erro: RPC falhou; resultado = 18, código HTTP = 20082 MiB | 6,26 MiB / s

fatal: EOF inicial

fatal: o terminal remoto desligou inesperadamente

fatal: o pacote de índices falhou

Isso também acontece quando seus árbitros estão usando muita memory. Podar a memory consertou isso para mim. Basta adicionar um limite para o que você está buscando como -> git fetch –depth = 100

Isso irá buscar os arquivos, mas com as últimas 100 edições em seus históricos. Depois disso, você pode fazer qualquer comando bem e na velocidade normal.

Eu desliguei todos os downloads que eu estava fazendo nesse meio tempo, o que liberou algum espaço provavelmente e limpou / diminuiu a largura de banda

O problema do git-daemon parece ter sido resolvido na v2.17.0 (verificado com um v2.16.2.1 que não funciona). Ou seja, a solução alternativa de selecionar o texto no console para “bloquear o buffer de saída” não deve mais ser necessária.

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

  • Correções variadas para “git daemon”. (mesclar ed15e58efe jk / daemon-corrige depois para maint).

Isso funcionou para mim, configurando o servidor de nomes do Google porque nenhum servidor de nomes padrão foi especificado, seguido pelo reinício da rede:

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

Nada disso funcionou para mim, mas usar a ferramenta embutida do Heroku fez o truque.

 heroku git:clone -a myapp 

Documentação aqui: https://devcenter.heroku.com/articles/git-clone-heroku-app

De um clone do git, eu estava recebendo:

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

Depois de reiniciar a máquina, consegui clonar o repo fine.

Se você está no Windows, você pode querer verificar se o git clone falha com o “index-pack” com falha? .

Basicamente, depois de executar o comando git.exe daemon ... , selecione algum texto dessa janela do console. Tente novamente puxar / clonar, pode funcionar agora!

Veja esta resposta para mais informações.