Isso geralmente significa que um processo ainda está usando esse arquivo específico (ainda tem um identificador)
(no Windows, ProcessExplorer
é bom em rastrear esse tipo de processo)
Tente fechar seus outros programas e tente novamente o seu git pull
.
Note-se que você tem uma alternativa com a GIT_ASK_YESNO
variável .
Atualize janeiro de 2019:
Isso deve ser ainda mais corrigido, com o Git 2.21 (primeiro trimestre de 2019), pois " git gc
" e " git repack
" não fecharam os arquivos de pacotes abertos que consideravam desnecessários antes de removê-los, o que não funcionava em uma plataforma incapaz de remover um arquivo aberto.
Isso foi corrigido.
Veja commit 5bdece0 (15 Dec 2018) por Johannes Schindelin ( dscho
) .
(Mesclado por Junio C Hamano - gitster
- in commit 5104f8f , 18 jan 2019)
gc
/repack
: libera pacotes quando necessário
No Windows, os arquivos não podem ser removidos nem renomeados se ainda houver identificadores retidos por um processo.
Para remediar isso, introduzimos oclose_all_packs()
função
Anteriormente, garantimos que os pacotes fossem liberados logo antes da git gc
geração, caso issogc
deseje remover os pacotes que não são mais necessários.
Mas esse desenvolvedor esqueceu que gc
também precisa liberar pacotes, por exemplo, ao consolidar todos os pacotes via--aggressive
opção.
Da mesma forma, git repack -d
deseja excluir pacotes obsoletos e, portanto, também precisa fechar todos os identificadores de pacote.
Atualização de janeiro de 2016
Isso deve ser corrigido no Git 2.8 (março de 2016) (e veja Git 2.19, terceiro trimestre de 2018 abaixo)
Consulte commit d562102 , commit dcacb1b , commit df617b5 , commit 0898c96 (13 de janeiro de 2016) por Johannes Schindelin ( dscho
) .
(Mesclado por Junio C Hamano - gitster
- na confirmação 3c80940 , 26 de janeiro de 2016)
fetch
: libere arquivos do pacote antes da coleta de lixo
Antes de fazer o gc'ing automático, precisamos garantir que os arquivos do pacote sejam liberados, caso precisem ser reembalados e coletados no lixo.
Muitos caminhos de código que " gc --auto
" executam antes de sair mantinham os arquivos de pacotes mapeados e deixaram os descritores de arquivos abertos para eles, o que não era amigável para sistemas que não podem remover arquivos abertos.
Eles agora fecham os pacotes antes de fazê-lo.
Isso corrige o git-for-widows
problema 500 .
Observando o teste usado para validar essa nova abordagem , uma possível solução alternativa (desde que o Git 2.8 ainda não foi lançado) seria aumentar artificialmente gc.autoPackLimit
.
git config gc.autoPackLimit 10000
git fetch
git config gc.autoPackLimit 50 # default value
O git 2.8.4 (junho de 2016) menciona o problema 755, que também deve aliviar o problema ( commit 2db0641 ):
Verifique se os identificadores de arquivo temporário não são herdados pelos processos filho
Na verdade, o git-for-windows
problema 500 mencionado acima foi realmente corrigido com o Git 2.19, terceiro trimestre de 2018.
Consulte " Git - Desvinculação do arquivo .idx
e .pack
falha (o único processo de propriedade desse arquivo é git.exe
) "