Como corrigir erro GIT: arquivo de objeto está vazio?

Quando tento confirmar alterações, recebo este erro:

error: object file .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0 is empty
fatal: loose object 3165329bb680e30595f242b7c4d8406ca63eeab0 (stored in .git/objects/31/65329bb680e30595f242b7c4d8406ca63eeab0) is corrupt

Alguma idéia de como resolver esse erro?

EDITAR

Eu tentei, git fsckeu tenho:

error: object file .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71 is empty
fatal: loose object 03dfd60a4809a3ba7023cbf098eb322d08630b71 (stored in .git/objects/03/dfd60a4809a3ba7023cbf098eb322d08630b71) is corrupt

Eu tive um problema parecido. Meu laptop ficou sem bateria durante uma operação git. Vaia.

Eu não tinha nenhum backup. (Nota: O Ubuntu One não é uma solução de backup para o git; ele substituirá o seu repositório sadio por um corrompido.)

Para os assistentes do git, se essa foi uma maneira ruim de corrigi-lo, deixe um comentário. No entanto, funcionou para mim ... pelo menos temporariamente.

Etapa 1: Faça um backup do .git (na verdade, eu faço isso entre todas as etapas que mudam algo, mas com uma nova cópia para o nome, por exemplo, .git-old-1, .git-old-2, etc.) :

cp -a .git .git-old

Etapa 2: executar git fsck --full

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

Etapa 3: Remova o arquivo vazio. Descobri, mas que droga; está em branco de qualquer maneira.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e 
rm: remove write-protected regular empty file `.git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e'? y

Etapa 3: execute git fscknovamente. Continue excluindo os arquivos vazios. Você também pode cdentrar no .gitdiretório e executar find . -type f -empty -delete -printpara remover todos os arquivos vazios. Eventualmente, o git começou a me dizer que estava realmente fazendo algo com os diretórios de objeto:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: object file .git/objects/e0/cbccee33aea970f4887194047141f79a363636 is empty
fatal: loose object e0cbccee33aea970f4887194047141f79a363636 (stored in .git/objects/e0/cbccee33aea970f4887194047141f79a363636) is corrupt

Etapa 4: depois de excluir todos os arquivos vazios, finalmente cheguei à git fsckexecução:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: HEAD: invalid sha1 pointer af9fc0c5939eee40f6be2ed66381d74ec2be895f
error: refs/heads/master does not point to a valid object!
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Etapa 5: tente git reflog. Falhar porque minha cabeça está quebrada.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reflog
fatal: bad object HEAD

Etapa 6: Google. Encontre isso . Obtenha manualmente as duas últimas linhas do reflog:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ tail -n 2 .git/logs/refs/heads/master
f2d4c4868ec7719317a8fce9dc18c4f2e00ede04 9f0abf890b113a287e10d56b66dbab66adc1662d Nathan VanHoudnos <[email protected]> 1347306977 -0400  commit: up to p. 24, including correcting spelling of my name
9f0abf890b113a287e10d56b66dbab66adc1662d af9fc0c5939eee40f6be2ed66381d74ec2be895f Nathan VanHoudnos <[email protected]> 1347358589 -0400  commit: fixed up to page 28

Etapa 7: Observe que, na Etapa 6, aprendemos que o HEAD está atualmente apontando para o último commit. Então, vamos tentar apenas olhar para o commit pai:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git show 9f0abf890b113a287e10d56b66dbab66adc1662d
commit 9f0abf890b113a287e10d56b66dbab66adc1662d
Author: Nathan VanHoudnos <nathanvan@XXXXXX>
Date:   Mon Sep 10 15:56:17 2012 -0400

    up to p. 24, including correcting spelling of my name

diff --git a/tex/MCMC-in-IRT.tex b/tex/MCMC-in-IRT.tex
index 86e67a1..b860686 100644
--- a/tex/MCMC-in-IRT.tex
+++ b/tex/MCMC-in-IRT.tex

Funcionou!

Etapa 8: agora precisamos apontar HEAD para 9f0abf890b113a287e10d56b66dbab66adc1662d.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git update-ref HEAD 9f0abf890b113a287e10d56b66dbab66adc1662d

O que não reclamou.

Etapa 9: veja o que o fsck diz:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
error: 0e31469d372551bb2f51a186fa32795e39f94d5c: invalid sha1 pointer in cache-tree
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
missing blob 8b61d0135d3195966b443f6c73fb68466264c68e
missing blob e89896b1282fbae6cf046bf21b62dd275aaa32f4
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a
missing blob caab8e3d18f2b8c8947f79af7885cdeeeae192fd
missing blob e4cf65ddf80338d50ecd4abcf1caf1de3127c229

Etapa 10: O ponteiro sha1 inválido na árvore de cache parecia ser de um arquivo de índice ( fonte desatualizado) (agora desatualizado ). Então eu o matei e redefinii o repositório.

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ rm .git/index
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git reset
Unstaged changes after reset:
M   tex/MCMC-in-IRT.tex
M   tex/recipe-example/build-example-plots.R
M   tex/recipe-example/build-failure-plots.R

Etapa 11: olhando para o fsck novamente ...

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git fsck --full
Checking object directories: 100% (256/256), done.
error: refs/heads/master.u1conflict does not point to a valid object!
dangling blob 03511c9868b5dbac4ef1343956776ac508c7c2a2
dangling blob dd09f7f1f033632b7ef90876d6802f5b5fede79a

Os blobs pendentes não são erros . Não estou preocupado com o conflito master.u1, e agora que está funcionando, não quero mais tocá-lo!

Etapa 12: atualizando minhas edições locais:

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   tex/MCMC-in-IRT.tex
#   modified:   tex/recipe-example/build-example-plots.R
#   modified:   tex/recipe-example/build-failure-plots.R
#
< ... snip ... >
no changes added to commit (use "git add" and/or "git commit -a")


nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "recovering from the git fiasco"
[master 7922876] recovering from the git fiasco
 3 files changed, 12 insertions(+), 94 deletions(-)

nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git add tex/sept2012_code/example-code-testing.R
nathanvan@nathanvan-N61Jq:~/workspace/mcmc-chapter$ git commit -a -m "adding in the example code"
[master 385c023] adding in the example code
 1 file changed, 331 insertions(+)
 create mode 100644 tex/sept2012_code/example-code-testing.R

Então espero que isso possa ser útil para as pessoas no futuro. Estou feliz que funcionou.

Os arquivos do objeto git ficaram corrompidos (como apontado em outras respostas também). Isso pode acontecer durante falhas na máquina, etc.

eu tive a mesma coisa. Depois de ler as outras respostas principais aqui, encontrei a maneira mais rápida de corrigir o repositório git quebrado com os seguintes comandos (execute no diretório de trabalho git que contém a .gitpasta):

(Certifique-se de fazer backup da pasta do repositório git primeiro!)

find .git/objects/ -type f -empty | xargs rm
git fetch -p
git fsck --full

Isso removerá primeiro qualquer arquivo de objeto vazio que cause corrupção no repositório como um todo e, em seguida, busca os objetos ausentes (bem como as alterações mais recentes) do repositório remoto e, em seguida, faz uma verificação completa do armazenamento de objetos . Que, neste momento, deve ter sucesso sem erros (ainda podem haver alguns avisos!)

PS. Esta resposta sugere que você tenha uma cópia remota do seu repositório git em algum lugar (por exemplo, no GitHub) e o repositório quebrado é o repositório local que está vinculado ao repositório remoto que ainda está intacto. Se não for esse o caso, não tente corrigi-lo da maneira que recomendo.

Este erro ocorre comigo quando estou pressionando meu commit e meu computador trava. É assim que eu consertei.

Etapas para corrigir

git status

mostra o arquivo de objeto vazio / corrompido

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

remova

git status

Eu recebi fatal: bad object HEADmensagem

rm .git/index

Eu removo o indexpara a redefinição

git reset

fatal: Não foi possível analisar o objeto 'HEAD'.

git status
git pull

apenas para verificar o que está acontecendo

tail -n 2 .git/logs/refs/heads/MY-CURRENT-BRANCH

imprime as duas últimas linhas tail -n 2da ramificação de log para mostrar minhas duas últimascommit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Eu escolho o ultimo commit hash

git status

mostra todo o meu arquivo como deletedporque eu removi o .git/indexarquivo

git reset

continue com a redefinição

git status

verificar minha correção

Nota: As etapas começam quando eu cheguei nesta pergunta e usei as respostas como referência.

Resolvi isso removendo os vários arquivos vazios que o git fsck estava detectando e executando um simples git pull.

Acho decepcionante que, agora que mesmo os sistemas de arquivos implementem o registro no diário e outras técnicas "transacionais" para manter o fs sadio, o git possa chegar a um estado corrompido (e não conseguir se recuperar sozinho) devido a uma falha de energia ou espaço no dispositivo.

Acabei de ter o mesmo problema: depois de puxar o repositório distante, quando fiz um status git, obtive: "error: o arquivo de objeto (...) está vazio" "fatal: o objeto solto (...) está corrompido"

A maneira que resolvi isso foi:

1. esconderijo
2. removendo o arquivo git com erro (não sei se é necessário)
3. esconder git claro

Não sei exatamente o que as coisas aconteceram, mas essas instruções pareciam deixar tudo limpo.

Como tenho que reiniciar minha VM regularmente, esse problema ocorre de alguma maneira comigo com muita frequência. Após algumas vezes, percebi que não posso repetir o processo descrito por @ Nathan-Vanhoudnos toda vez que isso acontece, embora sempre funcione. Então eu descobri a seguinte solução mais rápida.

Passo 1

Mova seu repositório inteiro para outra pasta.

mv current_repo temp_repo

Passo 2

Clone o repositório da origem novamente.

git clone source_to_current_repo.git

etapa 3

Retirar tudo sob o novo repositório, exceto o .git pasta .

Passo 4

Mova Tudo do temp_repo para o novo repositório, exceto o .git pasta .

Etapa 5

Remova o temp_repo e pronto.

Depois de algumas vezes, tenho certeza de que você pode executar esses procedimentos muito rapidamente.

1. mv seu aplicativo de pasta para fazer backup, ou seja, mv app_folder app_folder_bk (é como um stash git )
2. git clone seu_repositório
3. Finalmente,. Abra uma ferramenta de mesclagem (eu uso o meld diff viewer linux ou o Winmerge Windows) e copie as alterações da direita ( app_folder_bk ) para a esquerda (nova app_folder ) (é como uma aplicação de stash git ).

Isso é tudo. Talvez não seja o melhor caminho, mas acho que é tão prático.

No meu caso, esse erro ocorreu porque eu estava digitando a mensagem de confirmação e meu notebook foi desligado.

Eu executei estas etapas para corrigir o erro:

• git checkout -b backup-branch # Crie uma ramificação de backup
• git reset --hard HEAD~4# Redefina para o commit, onde tudo funciona bem. No meu caso, tive que voltar com 4 confirmações na cabeça, ou seja, até que minha cabeça estivesse no ponto antes de digitar a mensagem de confirmação. Antes de executar esta etapa, copie o hash dos commits que você redefinirá, no meu caso eu copiei o hash dos 4 últimos commits
• git cherry-pick <commit-hash> # Cherry escolhe as confirmações redefinidas (no meu caso, são 4 confirmações, então eu fiz essa etapa 4 vezes) do ramo antigo para o novo ramo.
• git push origin backup-branch # Empurre a nova ramificação para garantir que tudo funcione bem
• git branch -D your-branch # Exclua a ramificação localmente ('sua ramificação' é a ramificação com problema)
• git push origin :your-branch # Exclua a ramificação do controle remoto
• git branch -m backup-branch your-branch # Renomeie a ramificação de backup para ter o nome da ramificação que teve o problema
• git push origin your-branch # Empurre o novo ramo
• git push origin :backup-branch # Exclua a ramificação de backup do controle remoto

git stash
git checkout master
cd .git/ && find . -type f -empty -delete
git branch your-branch-name -D
git checkout -b your-branch-name
git stash pop

resolver meu problema

Aqui está uma maneira muito simples e rápida de lidar com esse problema, se você tiver um repositório local com todas as ramificações e confirmações necessárias e se estiver certo em criar um novo repositório (ou excluir o repositório do servidor e criar um novo) em seu lugar):

1. Crie um novo repositório vazio no servidor (ou exclua o antigo repositório e crie um novo em seu lugar)
2. Altere o URL remoto da sua cópia local para apontar para o URL remoto do novo repositório.
3. Envie todas as ramificações do seu repositório local para o novo repositório do servidor.

Isso preserva todo o histórico de submissões e ramificações que você tinha no seu repositório local.

Se você tiver colaboradores no repositório, acho que, em muitos casos, tudo o que seus colaboradores precisam fazer é alterar também o URL remoto do repositório local e, opcionalmente, enviar todos os commits que o servidor não possui.

Esta solução funcionou para mim quando me deparei com esse mesmo problema. Eu tive um colaborador. Depois de enviar meu repositório local para o novo repositório remoto, ele simplesmente mudou o repositório local para apontar para o URL do repositório remoto e tudo funcionou bem.

Suponho que você tenha um controle remoto com todas as alterações relevantes já enviadas. Eu não me importava com alterações locais e simplesmente queria evitar excluir e reclonar um repositório grande. Se você tiver alterações locais importantes, convém ter mais cuidado.

Eu tive o mesmo problema depois que meu laptop travou. Provavelmente, por ser um repositório grande, eu tinha muitos arquivos de objetos corrompidos, que só apareciam um de cada vez ao chamar git fsck --full, então escrevi um pequeno liner de shell para excluir automaticamente um deles:

$ sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`

• 2>&1 redireciona a mensagem de erro para stdout para poder cumprimentá-la
• opções de grep usadas:
  • -o retorna apenas a parte de uma linha que realmente corresponde
  • -E permite regexes avançadas
  • -m 1 verifique se apenas a primeira correspondência é retornada
  • [0-9a-f]{2} corresponde a qualquer um dos caracteres entre 0 e 9 e aef se dois deles ocorrerem juntos
  • [0-9a-f]* corresponde a qualquer número de caracteres entre 0 e 9 e a e f ocorrendo juntos

Ele ainda exclui apenas um arquivo de cada vez, portanto, convém chamá-lo em um loop como:

$ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; done

O problema é que ele não produz mais nada útil, portanto você não sabe quando está finalizado (ele não deve ser útil depois de algum tempo)

Para "consertar" isso, adicionei uma chamada de git fsck --full após cada rodada da seguinte maneira: $ while true; do sudo rm `git fsck --full 2>&1 | grep -oE -m 1 ".git/objects/[0-9a-f]{2}/[0-9a-f]*"`; git fsck --full; done

Agora é aproximadamente metade da velocidade, mas produz o "estado".

Depois disso, eu brinquei com algumas sugestões neste tópico e finalmente cheguei a um ponto em que eu podia git stashe git stash dropmuitas coisas quebradas.

primeiro problema resolvido

Depois, eu ainda tinha o seguinte problema: unable to resolve reference 'refs/remotes/origin/$branch': reference brokenque poderia ser resolvido por $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Então eu fiz um $ git gc --prune=now

$ git remote prune origin

por uma boa medida e

git reflog expire --stale-fix --all

para se livrar error: HEAD: invalid reflog entry $blubbao correr git fsck --full.

Vamos simplificar .. apenas no caso de você ter carregado a fonte no repositório remoto do git

1. Faça backup do seu .git

2. verifique seu git

   git fsck --full
   

3. remover arquivo de objeto vazio (todos)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. verifique seu git novamente.

   git fsck --full
   

5. retire sua fonte do git remoto

   git pull origin master
   

Eu me deparo muito com esse problema com máquinas virtuais.

Para mim, os seguintes trabalhos:

cd /path/to/your/project
rm -rf .git

Se você deseja salvar alguns downloads - entre no seu explorador de arquivos e exclua todos os arquivos da pasta que já foram confirmados e deixe nas pastas / vendor e / node_modules (eu trabalho com compositor e npm).

então basta criar um novo repositório

git init

adicione seu controle remoto

git remote add origin ssh://[email protected]/YourUsername/repoName.git

e buscar o ramo / tudo

git fetch origin somebranch

e confira

git checkout somebranch

então você deve estar no ponto antes do erro.

Espero que isto ajude.

Saudações.

Encontro o mesmo problema e uso uma maneira muito simples de corrigi-lo. Descobri que esses arquivos ausentes existiam no computador do meu companheiro de equipe.

I copiado esses arquivos um por um para um servidor git (9 arquivos total), e que resolveu o problema.

Meus colegas e eu já cruzamos várias vezes com esse mesmo problema e, para resolvê-lo, simplesmente executamos as etapas descritas abaixo. Não é a solução mais elegante que pode ser encontrada, mas funciona sem perda de dados.

1. Renomeie o diretório de trabalho atual. ( old_projectpara este exemplo).
2. Clone o repositório em um novo diretório usando git clone .
3. Na linha de comandos, altere o diretório ativo para o projeto recém-criado e alterne para a ramificação na qual você está trabalhando.
4. Copie todos os arquivos e diretórios dentro old_project(exceto o.git diretório) para o diretório do projeto recém-criado.
5. Verifique o status da sua árvore de trabalho (observe que há muito mais alterações do que o esperado) e confirme as alterações.

Espero que ajude...

Aqui está uma maneira de resolver o problema se seu repositório público no github.com estiver funcionando, mas seu repositório local estiver corrompido. Esteja ciente de que você perderá todos os commits que fez no repositório local.

Tudo bem, então eu tenho um repositório local que está me dando isso object empty error, e o mesmo repositório no github.com, mas sem esse erro. Então, o que eu simplesmente fiz foi clonar o repositório que está funcionando no github e depois copiar tudo do repositório corrompido (exceto a pasta .git) e colá-lo no repositório clonado que está funcionando.

Isso pode não ser uma solução prática (já que você exclui as confirmações locais), no entanto, você mantém o código e um controle de versão reparado.

Lembre-se de fazer backup antes de aplicar essa abordagem.

No meu caso, não era importante para mim manter o histórico de consolidação local. Portanto, se isso também se aplica a você, você pode fazer isso como uma alternativa rápida às soluções acima:

Você basicamente substitui o .git/diretório corrompido por um diretório limpo.

Vamos supor o seguinte diretório para o seu projeto com o git corrompido: projects/corrupt_git/

1. cp projects/corrupt_git projects/backup - (opcional) faça um backup
2. git clone [repo URL] projects/clean_git - para que você obtenha projects/clean_git
3. rm -rf corrupt_git/.git/ - remova a pasta .git corrompida
4. mv clean_git/.git/ corrupt_git/ - mova o git limpo para corrupt_git/.git
5. git statusin projects/corrupt_git- para garantir que funcionou

Copie tudo (na pasta que contém o .git) para um backup, exclua tudo e reinicie. Verifique se você tem o controle remoto git à mão:

git remote -v
 origin [email protected]:rwldrn/idiomatic.js.git (fetch)
 origin [email protected]:rwldrn/idiomatic.js.git (push)

Então

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin [email protected]:rwldrn/idiomatic.js.git

Em seguida, mescle todos os novos arquivos manualmente e tente manter o computador ligado.

Teve o mesmo problema depois de verificar o mestre de uma ramificação limpa. Depois de um tempo, reconheci muitos arquivos modificados no master. Não sei por que eles estiveram lá, depois de mudar de um galho limpo. De qualquer forma, como os arquivos modificados não faziam sentido para mim, apenas os escondi e o erro se foi.

git:(master) git stash

se você tiver um backup antigo e estiver com pressa:

faça um NOVO BACKUP do seu caminho atual do projeto, quebrado por git.

1. mova o seu .gitpara a lixeira (nunca exclua)
2. cópia de .git do backup antigo
3. git pull (criará conflitos de mesclagem)
4. mova todas as suas fontes (tudo o que você coloca no git) para o lixo: ./src (nunca exclua)
5. .copie todas as suas fontes (tudo o que você colocar no git) do NOVO BACKUP
6. aceite todas as "mesclagens" em git gui, empurre e ... bata palmas!

A solução de doze etapas abordada acima me ajudou a me livrar de um congestionamento. Obrigado. As principais etapas foram inserir:

git fsck --full 

e remova todos os objetos vazios

rm .git/objects/...

Depois, pegue as duas linhas do chicote:

tail -n 2 .git/logs/refs/heads/master

Com os valores retornados

git update-ref HEAD ...

Nesse ponto, não havia mais erros, então fiz um backup dos meus arquivos mais recentes. Em seguida, faça um git pull seguido de um git push. Copiei meus backups para o meu arquivo de repositório git e fiz outro push git. Isso me deixou atualizado.

Corrigi o erro git: o arquivo de objeto está vazio por:

1. Salvando uma cópia de todos os arquivos que editei desde a última confirmação / envio bem-sucedido,
2. Removendo e clonando novamente meu repositório,
3. Substituindo os arquivos antigos pelos meus arquivos editados.

Espero que isso ajude.

Isso também acontece comigo quase regularmente. Não fiz um protocolo quando isso acontece exatamente, mas suspeito que ocorra sempre que minha máquina virtual existir "inesperadamente". Se eu fechar a janela da VM (estou usando o Ubuntu 18.04) e começar de novo, as coisas sempre (?) Funcionam. Mas se a janela da VM ainda estiver aberta quando meu laptop for desligado (sistema host do Windows), encontro esse problema com bastante frequência.

Quanto a todas as respostas dadas aqui:

1. obrigado - eles são muito úteis; Normalmente, salvo uma cópia local do meu código, restauro o repositório do controle remoto e movo a cópia de backup de volta para a pasta local.

2. como o problema subjacente não é realmente um problema de git, mas sim um problema de VM e / ou Linux, pergunto-me se não deveria haver uma maneira de curar a razão, e sim os sintomas? Esse tipo de erro não indica que algumas alterações no sistema de arquivos não são "aplicadas" em um tempo razoável, mas apenas armazenadas em cache? (veja, por exemplo, /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - para mim, parece que as máquinas Linux virtuais não sincronize as coisas com frequência suficiente. Se esse é um problema do VirtualBox da Oracle (que de outra forma funciona muito bem) ou do sistema de arquivos convidado, ou de algumas configurações que todos ignoramos, está além da minha experiência. Mas eu ficaria feliz se alguém pudesse esclarecer isso.

Na verdade, eu tive o mesmo problema. Tenha uma cópia do seu código antes de tentar isso.

eu apenas fiz git reset HEAD~

meu último commit foi desfeito, então eu o cometi novamente, problema resolvido!

Atenção: Com mais experiência, percebo que essa é a opção nuclear e normalmente não deve ser feita e não ensina nada. No entanto, em raras ocasiões para projetos pessoais, eu ainda achei útil, então estou deixando para lá.

Se você não se preocupa em manter seus comprometimentos históricos, basta executar

rm -r .git

Em seguida, responda sim a qualquer pergunta sobre a exclusão de arquivos protegidos contra gravação. Problema resolvido em menos de um minuto.