¿Cómo reparar el error GIT: el archivo de objeto está vacío?

Cuando intento confirmar los cambios, aparece este error:

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

¿Alguna idea de cómo resolver este error?

EDITAR

Intenté git fscktengo:

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

Tuve un problema similar. Mi computadora portátil se quedó sin batería durante una operación git. Abucheo.

No tenía ninguna copia de seguridad. (NB Ubuntu One no es una solución de respaldo para git; útilmente sobrescribirá su repositorio cuerdo con el corrupto).

Para los magos git, si esta fue una mala manera de solucionarlo, por favor dejen un comentario. Sin embargo, funcionó para mí ... al menos temporalmente.

Paso 1: haga una copia de seguridad de .git (de hecho, hago esto entre cada paso que cambia algo, pero con un nuevo nombre de copia, por ejemplo .git-old-1, .git-old-2, etc.) :

cp -a .git .git-old

Paso 2: ejecutar 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

Paso 3: elimine el archivo vacío. Pensé por qué no; está en blanco de todos modos.

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

Paso 3: corre de git fscknuevo. Continúa eliminando los archivos vacíos. También puede cdingresar al .gitdirectorio y ejecutar find . -type f -empty -delete -printpara eliminar todos los archivos vacíos. Finalmente, git comenzó a decirme que en realidad estaba haciendo algo con los directorios de objetos:

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

Paso 4: Después de eliminar todos los archivos vacíos, finalmente llegué a git fsckejecutar:

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

Paso 5: Inténtalo git reflog. Fallo porque mi CABEZA está rota.

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

Paso 6: Google. Encuentra esto . Obtenga manualmente las dos últimas líneas del reflog:

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

Paso 7: Tenga en cuenta que del Paso 6 aprendimos que HEAD está apuntando al último commit. Así que tratemos de ver el commit principal:

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

¡Funcionó!

Paso 8: Entonces, ahora debemos apuntar HEAD a 9f0abf890b113a287e10d56b66dbab66adc1662d.

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

Lo cual no se quejó.

Paso 9: mira lo que dice fsck:

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

Paso 10: el puntero sha1 no válido en el árbol de caché parecía que era de un archivo de índice ( fuente ) ahora desactualizado . Así que lo maté y reinicié el repositorio.

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

Paso 11: Mirando el fsck nuevamente ...

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

Las gotas colgantes no son errores . No estoy preocupado por master.u1conflict, y ahora que está funcionando, ¡ya no quiero tocarlo!

Paso 12: Ponerme al día con mis ediciones locales:

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

Espero que eso pueda ser de alguna utilidad para las personas en el futuro. Me alegra que haya funcionado.

Los archivos de objetos git se han dañado (como se señala en otras respuestas también). Esto puede suceder durante bloqueos de la máquina, etc.

Yo tuve lo mismo. Después de leer las otras respuestas principales aquí, encontré la forma más rápida de arreglar el repositorio de git roto con los siguientes comandos (ejecutar en el directorio de trabajo de git que contiene la .gitcarpeta):

(¡Asegúrese de hacer una copia de seguridad de su carpeta de repositorio git primero!)

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

Esto eliminará primero los archivos de objetos vacíos que causen la corrupción del repositorio en su conjunto, y luego buscará los objetos faltantes (así como los últimos cambios) del repositorio remoto y luego realizará una comprobación completa del almacén de objetos . Lo cual, en este punto, debería tener éxito sin ningún error (¡aunque puede haber algunas advertencias!)

PD. Esta respuesta sugiere que tiene una copia remota de su repositorio git en algún lugar (por ejemplo, en GitHub) y el repositorio roto es el repositorio local que está vinculado al repositorio remoto que todavía está intacto. Si ese no es el caso, no intente arreglarlo de la manera que le recomiendo.

Este error me ocurre cuando estoy presionando mi confirmación y mi computadora se cuelga. Así es como lo solucioné.

Pasos para arreglar

git status

muestra el archivo de objeto vacío / corrupto

rm .git/objects/08/3834cb34d155e67a8930604d57d3d302d7ec12

eliminarlo

git status

Recibí un fatal: bad object HEADmensaje

rm .git/index

Elimino el indexpara el reinicio

git reset

fatal: no se pudo analizar el objeto 'HEAD'.

git status
git pull

solo para ver qué pasa

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

imprime las últimas 2 líneas tail -n 2de rama de registro para mostrar mis 2 últimascommit hash

git update-ref HEAD 7221fa02cb627470db163826da4265609aba47b2

Elijo el último commit hash

git status

muestra todo mi archivo como deletedporque eliminé el .git/indexarchivo

git reset

continuar con el reinicio

git status

verificar mi arreglo

Nota: Los pasos comienzan cuando llegué a esta pregunta y usé las respuestas como referencia.

Resolví esto eliminando los diversos archivos vacíos que git fsck estaba detectando, y luego ejecuté un simple git pull.

Me parece decepcionante que ahora que incluso los sistemas de archivos implementan el registro en diario y otras técnicas "transaccionales" para mantener la salud mental, git puede llegar a un estado corrupto (y no ser capaz de recuperarse por sí mismo) debido a una falla de energía o espacio en el dispositivo.

Acabo de tener el mismo problema: después de extraer el repositorio distante, cuando hice un estado git obtuve: "error: el archivo de objeto (...) está vacío" "fatal: el objeto suelto (...) está dañado"

La forma en que resolví esto fue:

1. escondite
2. eliminando el archivo git por error (no estoy seguro de que sea necesario)
3. git stash clear

No sé exactamente qué sucedieron, pero esas instrucciones parecían aclarar todo.

Debido a que tengo que reiniciar mi VM con regularidad, de alguna manera este problema me ocurre muy a menudo. Después de algunas veces, me di cuenta de que no puedo repetir el proceso descrito por @ Nathan-Vanhoudnos cada vez que esto sucede, aunque siempre funciona. Luego descubrí la siguiente solución más rápida.

Paso 1

Mueva su repositorio completo a otra carpeta.

mv current_repo temp_repo

Paso 2

Clonar el repositorio desde el origen nuevamente.

git clone source_to_current_repo.git

Paso 3

Elimine todo en el nuevo repositorio excepto la carpeta .git .

Paso 4

Mueva todo desde temp_repo al nuevo repositorio excepto la carpeta .git .

Paso 5

Elimine el temp_repo , y hemos terminado.

Después de algunas veces, estoy seguro de que puede realizar estos procedimientos muy rápidamente.

1. mv su aplicación de carpeta para hacer una copia de seguridad, es decir, mv app_folder app_folder_bk (es como un alijo git )
2. git clone your_repository
3. Finalmente,. Abra una herramienta de combinación (uso meld diff viewer linux o Winmerge Windows) y copie los cambios de derecha ( app_folder_bk ) a izquierda (nueva app_folder ) (es como si se aplicara un git stash ).

Eso es todo. Quizás no sea la mejor manera, pero creo que es muy práctico.

En mi caso, este error ocurrió porque estaba escribiendo el mensaje de confirmación y mi computadora portátil se apagó.

Hice estos pasos para corregir el error:

• git checkout -b backup-branch # Crear una rama de respaldo
• git reset --hard HEAD~4# Restablecer el commit donde todo funciona bien. En mi caso, tuve que respaldar 4 commits en la cabeza, es decir, hasta que mi cabeza estuviera en el punto antes de escribir el mensaje de confirmación. Antes de hacer este paso, copie el hash de los commits que restablecerá, en mi caso copié el hash de los 4 últimos commits
• git cherry-pick <commit-hash> # Cherry selecciona los commits reseteados (en mi caso son 4 commits, así que hice este paso 4 veces) de la rama anterior a la nueva rama.
• git push origin backup-branch # Empuje la nueva sucursal para asegurarse de que todo funcione bien
• git branch -D your-branch # Eliminar la rama localmente ('your-branch' es la rama con el problema)
• git push origin :your-branch # Eliminar la rama del control remoto
• git branch -m backup-branch your-branch # Cambie el nombre de la rama de respaldo para que tenga el nombre de la rama que tuvo el problema
• git push origin your-branch # Empuje la nueva rama
• git push origin :backup-branch # Eliminar la rama de respaldo del control 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

resuelve mi problema

Aquí hay una manera realmente simple y rápida de tratar este problema SI tiene un repositorio local con todas las ramas y compromisos que necesita, y si está de acuerdo con crear un nuevo repositorio (o eliminar el repositorio del servidor y hacer uno nuevo) en su lugar):

1. Cree un nuevo repositorio vacío en el servidor (o elimine el antiguo repositorio y cree uno nuevo en su lugar)
2. Cambie la URL remota de su copia local para que apunte a la URL remota del nuevo repositorio.
3. Empuje todas las ramas de su repositorio local al nuevo repositorio del servidor.

Esto conserva todo el historial de confirmación y las ramas que tenía en su repositorio local.

Si tiene colaboradores en el repositorio, creo que en muchos casos todo lo que sus colaboradores tienen que hacer es cambiar también la URL remota de su repositorio local y, opcionalmente, enviar las confirmaciones que tengan que el servidor no tiene.

Esta solución funcionó para mí cuando me encontré con este mismo problema. Tuve un colaborador. Después de enviar mi repositorio local al nuevo repositorio remoto, simplemente cambió su repositorio local para que apuntara a la URL del repositorio remoto y todo funcionó bien.

Supongo que tiene un control remoto con todos los cambios relevantes ya implementados. No me importaban los cambios locales y simplemente quería evitar eliminar y volver a clasificar un repositorio grande. Si tiene cambios locales importantes, puede ser más cuidadoso.

Tuve el mismo problema después de que mi computadora portátil se estrellara. Probablemente debido a que era un repositorio grande, tenía bastantes archivos de objetos corruptos, que solo aparecían uno a la vez cuando llamaba git fsck --full, así que escribí un pequeño shell de una línea para eliminar automáticamente uno de ellos:

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

• 2>&1 redirige el mensaje de error a stdout para poder grep
• Opciones de grep utilizadas:
  • -o solo devuelve la parte de una línea que realmente coincide
  • -E habilita expresiones regulares avanzadas
  • -m 1 asegúrese de que solo se devuelva el primer partido
  • [0-9a-f]{2} coincide con cualquiera de los caracteres entre 0 y 9 y a y f si dos de ellos aparecen juntos
  • [0-9a-f]* coincide con cualquier número de caracteres entre 0 y 9 y a y f aparecen juntos

Todavía solo elimina un archivo a la vez, por lo que es posible que desee llamarlo en un bucle 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

El problema con esto es que ya no genera nada útil, por lo que no sabe cuándo está terminado (simplemente no debería hacer nada útil después de un tiempo)

Para "arreglar" esto, simplemente agregué una llamada git fsck --fulldespués de cada ronda así: $ 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

Ahora es aproximadamente la mitad de rápido, pero genera su "estado".

Después de esto, jugué con algunas sugerencias en este hilo y finalmente llegué a un punto en el que pude git stashy git stash dropmuchas de las cosas rotas.

primer problema resuelto

Después todavía tenía el siguiente problema: unable to resolve reference 'refs/remotes/origin/$branch': reference brokenque podría resolverse con $ rm \repo.git\refs\remotes\origin\$branch

$ git fetch

Entonces hice un $ git gc --prune=now

$ git remote prune origin

por si acaso y

git reflog expire --stale-fix --all

deshacerse de error: HEAD: invalid reflog entry $blubbcuando se ejecuta git fsck --full.

Vayamos de manera simple ... solo en caso de que hayas subido la fuente al repositorio remoto de git

1. Copia de seguridad de tu .git

2. revisa tu git

   git fsck --full
   

3. eliminar el archivo de objeto vacío (todo)

   rm .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e
   

4. revisa tu git de nuevo.

   git fsck --full
   

5. saca tu fuente de git remoto

   git pull origin master
   

Me encuentro mucho con este problema con las máquinas virtuales.

Para mí los siguientes trabajos:

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

Si desea guardar algunas descargas, vaya a su explorador de archivos y elimine todos los archivos de la carpeta que ya están confirmados y deje en sus carpetas / vendor y / node_modules (trabajo con el compositor y npm).

entonces solo crea un nuevo repositorio

git init

agrega tu control remoto

git remote add origin ssh://git@github.com/YourUsername/repoName.git

y buscar la rama / todo

git fetch origin somebranch

y échale un vistazo

git checkout somebranch

entonces deberías estar en el punto antes del error.

Espero que esto ayude.

Saludos.

Me encuentro con el mismo problema, y ​​uso una forma muy simple de solucionarlo. Descubrí que esos archivos faltantes existían en la computadora de mi compañero de equipo.

Yo copié los archivos uno a uno a un servidor Git (9 archivos en total), y que solucionó el problema.

Mis colegas y yo nos hemos cruzado varias veces con este mismo problema y para resolverlo simplemente hacemos los pasos que describo a continuación. No es la solución más elegante que se puede encontrar, pero funciona sin pérdida de datos.

1. Cambie el nombre del directorio de trabajo actual. ( old_projectpara este ejemplo).
2. Clone el repositorio dentro de un nuevo directorio usando git clone.
3. En la línea de comando, cambie el directorio de trabajo al proyecto recién creado y cambie a la rama en la que ha estado trabajando.
4. Copie todos los archivos y directorios dentro old_project(excepto el .gitdirectorio) al directorio del proyecto recién creado.
5. Verifique el estado de su árbol de trabajo (tenga en cuenta que hay muchos más cambios de los que espera) y luego confirme los cambios.

Espero que ayude...

Aquí hay una manera de resolver el problema si su repositorio público en github.com está funcionando, pero su repositorio local está corrupto. Tenga en cuenta que perderá todas las confirmaciones que ha realizado en el repositorio local.

Muy bien, tengo un repositorio local que me da esto object empty error, y el mismo repositorio en github.com, pero sin este error. Entonces, lo que simplemente hice fue clonar el repositorio que funciona desde github, y luego copié todo desde el repositorio corrupto (excepto la carpeta .git), y pegué el repositorio clonado que funciona.

Esto puede no ser una solución práctica (ya que elimina las confirmaciones locales), sin embargo, mantiene el código y un control de versión reparado.

Recuerde hacer una copia de seguridad antes de aplicar este enfoque.

En mi caso, no era importante para mí mantener el historial de confirmación local. Entonces, si eso también se aplica a usted, puede hacer esto como una alternativa rápida a las soluciones anteriores:

Básicamente, simplemente reemplaza el .git/directorio dañado por uno limpio.

Supongamos el siguiente directorio para su proyecto con el git dañado: projects/corrupt_git/

1. cp projects/corrupt_git projects/backup - (opcional) hacer una copia de seguridad
2. git clone [repo URL] projects/clean_git - para que consigas projects/clean_git
3. rm -rf corrupt_git/.git/ - eliminar la carpeta corrupta .git
4. mv clean_git/.git/ corrupt_git/ - mover git limpio a corrupt_git/.git
5. git statusen projects/corrupt_git- para asegurarse de que funcionó

Copie todo (en la carpeta que contiene el .git) a una copia de seguridad, luego elimine todo y reinicie. Asegúrese de tener el control remoto git a mano:

git remote -v
 origin git@github.com:rwldrn/idiomatic.js.git (fetch)
 origin git@github.com:rwldrn/idiomatic.js.git (push)

Entonces

mkdir mygitfolder.backup
cp mygitfolder/* mygitfolder.backup/
cd mygitfolder
rm -r * .git*
git init
git remote add origin git@github.com:rwldrn/idiomatic.js.git

Luego combine los archivos nuevos manualmente e intente mantener su computadora encendida.

Tuve el mismo problema después de retirar el maestro de una rama limpia. Después de un tiempo reconocí muchos archivos modificados en master. No sé por qué han estado allí, después de cambiar de una rama limpia. De todos modos, debido a que los archivos modificados no tenían sentido para mí, simplemente los escondí y el error desapareció.

git:(master) git stash

si tiene una copia de seguridad ANTIGUA y tiene prisa:

haga una NUEVA COPIA DE SEGURIDAD de su ruta de proyecto actual, rota por git.

1. mover .gita la papelera (nunca eliminar)
2. copia .gitde la copia de seguridad ANTIGUA
3. git pull (creará conflictos de fusión)
4. mueva todas sus fuentes (todo lo que ponga en git) a la papelera: ./src (nunca elimine)
5. Copie todas sus fuentes (todo lo que ponga en git) de la NUEVA COPIA DE SEGURIDAD
6. acepta todas las "fusiones" en git gui, empuja y ... ¡aplaude!

La solución de doce pasos cubierta anteriormente también me ayudó a salir de un atasco. Gracias. Los pasos clave fueron ingresar:

git fsck --full 

y eliminar todos los objetos vacíos

rm .git/objects/...

Luego obteniendo las dos líneas del flog:

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

Con los valores devueltos

git update-ref HEAD ...

En este punto no tenía más errores, así que hice una copia de seguridad de mis archivos más recientes. Luego haz un git pull seguido de un git push. Copié mis copias de seguridad en mi archivo de repositorio git e hice otro empuje git. Eso me puso al corriente.

Arreglé mi error de git: el archivo de objeto está vacío por:

1. Guardando una copia de todos los archivos que edité desde mi último commit / push exitoso,
2. Eliminar y volver a clonar mi repositorio,
3. Reemplazar los archivos antiguos con mis archivos editados.

Espera que esto ayude.

Esto también me pasa casi regularmente. No he hecho un protocolo cuando esto sucede exactamente, pero sospecho que ocurre cada vez que mi máquina virtual existe "inesperadamente". Si cierro la ventana de VM (estoy usando Ubuntu 18.04) y empiezo de nuevo, las cosas siempre funcionan (?). Pero si la ventana de VM todavía está abierta cuando mi computadora portátil se apaga (sistema host de Windows), entonces encuentro este problema con bastante frecuencia.

En cuanto a todas las respuestas dadas aquí:

1. gracias, son muy útiles; Por lo general, guardo una copia local de mi código, restauro el repositorio desde el control remoto y muevo la copia de respaldo a la carpeta local.

2. Como el problema subyacente no es realmente un problema de git, sino más bien un problema de VM y / o Linux, me pregunto si no debería haber una manera de curar la razón, sino los síntomas. ¿Este tipo de error no indica que algunos cambios en el sistema de archivos no se "aplican" en un tiempo razonable, sino que solo se almacenan en caché? (ver por ejemplo /unix/464184/are-file-edits-in-linux-directly-saved-into-disk ) - para mí parece que las máquinas Linux virtuales no fsynch sus cosas con suficiente frecuencia. Si esto es un problema de VirtualBox de Oracle (que de otro modo funciona muy bien) o del sistema de archivos invitado, o de algunas configuraciones, que todos pasamos por alto, está más allá de mi experiencia. Pero sería feliz si alguien pudiera arrojar luz sobre esto.

En realidad tuve el mismo problema. Tenga una copia de su código antes de intentar esto.

Lo acabo de hacer git reset HEAD~

mi último compromiso se deshizo y luego lo cometí nuevamente, ¡problema resuelto!

Advertencia: con más experiencia, me doy cuenta de que esta es la opción nuclear y, por lo general, no debe hacerse y no enseña nada. Sin embargo, en raras ocasiones para proyectos personales, todavía lo encuentro útil, así que lo dejo.

Si no le importa mantener sus confirmaciones históricas, simplemente ejecute

rm -r .git

Luego responda sí a cualquier pregunta sobre la eliminación de archivos protegidos contra escritura. Problema resuelto en menos de un minuto.