Git 'fatal: Não foi possível gravar o novo arquivo de índice'

Eu já vi muitos dos outros tópicos sobre isso e eles não ajudam.

Eu tenho um repositório muito simples - dois arquivos JavaScript. Eu tenho mais de 100 GB no Macbook. Quando tento mover os arquivos para um subdiretório e preparar localmente as alterações que recebo ...

fatal: Não foi possível gravar o novo arquivo de índice

Isso acontece se eu faço todas as ações no terminal ou se eu uso uma GUI como o SourceTree. Além disso, um dos arquivos fica bloqueado e não posso excluir o diretório ativo até que eu efetue logoff e logon novamente.

Por que isso está acontecendo? A trava está impedindo que algo seja preparado? Se sim, o que / como desbloquear o arquivo com problema no OS X ?? O repo remoto é o Google Code, se isso faz diferença, embora eu ainda não esteja empurrando para o controle remoto. Tudo é local.

No meu caso, o disco ficou sem espaço, então tive que excluir arquivos do disco rígido para liberar espaço.

Eu tenho esse mesmo problema nos últimos dias. Basicamente, sem o meu conhecimento, todo o repositório foi movido para um novo sistema de arquivos; quando tentei executar o status git, foi repentinamente relatado que todos os arquivos no repositório foram atualizados.

Soluções possíveis

Então, depois de muita pesquisa no google, tentei o seguinte:

• alterando permssions .git (mesmo problema)
• alterando permissões .git / index (mesmo problema)
• git adicionando todas as alterações a serem confirmadas (mesmo problema)
• arquivos apagados do git rm-ing, pois estavam relatando erros muito longos no nome do arquivo (mesmo problema)
• git reset (suave | Cabeça | Difícil) (mesmo problema)
• git clean (o mesmo problema)
• desativando o Windows Defender (mesmo problema)
• atualizando o git (mesmo problema)
• clientes git diferentes (eu uso o gitbash) (mesmo problema)
• beber 2 cafés em vez de 1 (mesmo problema)

tl: dr - solução suja

A única coisa que conseguiu resolver o problema foi copiar o arquivo de índice, excluir o original e renomear a cópia.

Eu sei que não é realmente uma 'solução', mas agora está funcionando magicamente> <, com todos os arquivos / ramificações intactos. Se alguém souber por que isso pode dar certo, conte.

No meu caso, pausar a sincronização da caixa de depósito resolveu o problema

Eu tive o mesmo problema em um Mac. Parece ser causado por ACLs do sistema de arquivos. Tente chmod -RN /path/to/repolimpar as ACLs. Depois de fazer isso, consegui fazer alterações. Usando o truque para copiar o arquivo de índice, exclua o original e mova a cópia para trás, obtendo o mesmo resultado.

Se você tiver configurado o github em algum tipo de serviço de sincronização online, como o google drive ou o dropbox, tente desativar a sincronização, pois o serviço de sincronização tenta ler / gravar no arquivo, pois o github tenta fazer o mesmo, levando o github a não funcionar. corretamente.

Ocorreu-me que o arquivo .git / index estava em uso por outro processo (meu servidor da web de desenvolvimento local). Encerrei o processo e funcionou.

Fechar o código do Visual Studio (que, no meu caso, tem um trabalho em segundo plano do upload automático em execução no salvamento de arquivo) resolveu o problema para mim.

Crédito pela solução: meu amigo e colega Arnel.

Isso funcionou para mim:

rm -f ./.git/index.lock

No meu caso, a solução estava apenas adicionando permissão ao novo usuário.

Quando instalei o novo sistema operacional, movi meus repositórios e ele estava mostrando esse erro exato. Selecionei a pasta raiz e adicionei o usuário autenticado para verificar todas

Eu tinha o ACL (de alguma forma) anexado a todos os arquivos na pasta .git.

Verifique-o ls -lena pasta .git.

Você pode remover a ACL com chmod -N(para uma pasta / arquivo) ou chmod -RN(recursiva)

Acho que algumas soluções de backup em segundo plano, como o Google Backup e o Sync, bloqueiam o acesso ao arquivo de índice. Fechei o aplicativo e o Sourcetree não teve nenhum problema. Parece que o Dropbox faz o mesmo (@tonymayoral).

No meu caso, era um EGit em execução simultâneo. Depois de reiniciar o eclipse, ele funciona normalmente.

Se você estiver em uma caixa do Windows, verifique se o programa que está usando, seja na Árvore de Origem ou em um terminal git, está sendo executado como administrador. Eu estava recebendo a mesma mensagem de erro exata. Você pode clicar com o botão direito do mouse no programa para executar como administrador ou alterar suas propriedades para sempre executar como administrador.

Não ter espaço suficiente é um problema. Limpeza e tente novamente

Eu tive o mesmo problema. Reiniciei o computador e o problema foi resolvido.

você tentou 'git add'? . será que todas as mudanças? (você pode remover arquivos adicionados desnecessários pressionando git reset HEAD)

A mensagem de erro fatal: Unable to write new index filesignifica que não foi possível gravar o novo conteúdo no arquivo de índice git .git\index(veja aqui para obter mais informações sobre o índice git). Depois de revisar todas as respostas a esta pergunta, sumario as seguintes causas principais:

• O tamanho do novo conteúdo excede a capacidade disponível do disco. ( Solução : Limpe os espaços em disco)
• Os usuários não têm acesso direto a este arquivo. ( Solução : conceda a permissão)
• Os usuários têm permissão, mas .git\indexestão bloqueados por outros usuários ou processos. ( Solução : desbloqueie o arquivo)

O link Descubra qual processo está bloqueando um arquivo ou pasta no Windows especifica a seguinte abordagem para descobrir o processo que está bloqueando um arquivo específico:

SysInternals Process Explorer - Vá para Localizar> Localizar identificador ou DLL. Na caixa de texto "Manipulação ou substring DLL:", digite o caminho para o arquivo (por exemplo, "C: \ path \ to \ file.txt") e clique em "Pesquisar". Todos os processos que possuem um identificador aberto para esse arquivo devem ser listados.

Use a abordagem acima para descobrir qual processo está bloqueado .git\indexe, em seguida, pare o executável do bloqueio. Isso desbloqueia .git\index.

Por exemplo, a Process Explorer Search mostra que .git\indexestá bloqueado por vmware-vmx.exe. Suspender a máquina virtual do VMWare Player (que acessou o repositório git por meio de uma pasta compartilhada) resolveu o problema.

SE VOCÊ OBTER ISTO DURANTE UMA REBASE:

Provavelmente, isso é causado por algum software que bloqueia o arquivo de índice do seu repositório, como software de backup, antivírus, IDEs ou outros clientes git.

Na maioria dos casos, o bloqueio é apenas por um breve momento e, portanto, acontece fora do momento oportuno e da má sorte.

No entanto, git rebase --continuereclamará que o próximo comando seja um commit vazio:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Para corrigir isso, basta executar git resete tentar git rebase --continuenovamente.

Problema: quando eu estava verificando alguns arquivos modificados no git, recebi esse erro. Eu estava tendo dois usuários ABC e XYZ. os arquivos estão tendo uid: gid do ABC, mas ele não tem acesso ao git e tenta fazer check-out dos arquivos com o mesmo.

A solução que eu tentei: XYZ é ter acesso ao git, tentei verificar arquivos com o sudo e funcionou .. !!

Aqui está o que funcionou para mim:

Contexto:

1. Construindo um projeto em um servidor

2. git status retorna um HEAD detached at <commit-SHA>

3. Qualquer operação que eu fiz localmente, tive esse erro. Mais especificamente:

   • git checkout
   • git reset HEAD --hard

Solução

1. Arquivo simplesmente removido <work-dir>/.git/index.
2. A git statusindica que todos os arquivos no projeto não são rastreados (nenhuma surpresa aqui).
3. git reset HEAD --hard
4. De volta ao HEAD detached at <commit-SHA>fazer um git status, mas você deve ser capaz de
5. git checkout <some-branch>

e você está de volta aos trilhos!

!! IMPORTANTE !!

Isso funciona apenas porque estou construindo "meramente". Nenhuma modificação preciosa foi realizada no código. Se você estiver realmente em "dev-time", recomendo salvar o seu trabalho primeiro ou seguir outro método.

Espero que ajude :).

Eu tive esse problema usando GitExtensions no Windows. Corrigido ao conceder permissão total para o usuário atual (eu) na pasta que continha o repositório.

Em outra ocasião, mesmo tendo recebido o erro do Git Extensions, consegui confirmar os mesmos arquivos do Visual Studio 2015.

Outra vez, tive que excluir o arquivo "index" da pasta .git

Meu caso é um pouco interessante:

Eu corro o git log para verificar um determinado commit, então não o encerrei corretamente, pressione ctrl + c para sair.

Então o índice parece estar bloqueado. Então, eu executo o git log novamente e pressione Q para encerrá-lo.

Problema resolvido. :)

No meu caso, foi uma nodemoninstância observando o sistema de arquivos para alterações.