¿Hay alguna forma de que pueda reparar mi repositorio con el historial de confirmación en el tacto.Registro de Git: el objeto fatal [sha1] está dañado
# git log
fatal: object 01aeb2bf2e93b238f0e0422816b3e55518321ae7 is corrupted
Al leer el siguiente enlace, parece que voy a tener que borrarlo y empezar de nuevo.
http://www.miek.nl/s/7e76eadefe/
¿Tiene clones de este repositorio en otro lugar? Es posible que desee leer this post por Linus Torvalds para restaurar ese objeto dañado, suponiendo que el objeto dañado es un blob (contenido del archivo).
Sin clones. Acabo de configurar esto ayer. Entonces solo tuve 10 commits. Terminé empezando de nuevo. Pero definitivamente lo empujará a otro lugar al final de cada día. Lección aprendida. Todavía estoy contento de estar apagado svn. ¡Git es rápido! – Keyo
Sería útil incluir la esencia de la publicación en su respuesta, solo en caso, por ejemplo, kernal.org alguna vez es pirateado y está fuera de línea :( – SpoonMeiser
Terminé en la misma situación, probablemente debido a un apagado incorrecto de la máquina virtual en la que estaba trabajando. Había aproximadamente 10 objetos en .git/objetos que tenían longitud cero. Por lo que puedo decir, los archivos del código fuente real estaban bien, solo el repositorio estaba con mangueras.
$ git status
fatal: object fbcf234634ee04f8406cfd250ce5ab8012f92b08 is corrupted
por algunas sugerencias que he visto en otro lugar (incluyendo el post de Linus referencia más arriba), he intentado desplazar temporalmente el git objetos dañados se quejaba de .git/objetos en otro lugar. Cuando se había movido todos ellos, conseguí:
$ git status
fatal: bad object HEAD
Después de una hora de buscar en Google y tratando diferentes soluciones, me di por vencido y comenzó una nueva copia de trabajo utilizando 'git clone' para tirar desde el origen (que era aproximadamente 2 horas detrás de mi copia de trabajo). Luego utilicé rsync -rC (-C excluye archivos SCM) para copiar los archivos modificados de la copia de trabajo defectuosa a mi nueva copia de trabajo.
¡Gracias! Parece funcionar para mí. Desastre evitado. – DevX
Igual que aquí la corrupción de VM. rsync funcionó a la perfección, nada perdido, solo el registro que fue fácil de recrear. ¡Gracias! –
También podría tratar de restaurar estos objetos simplemente copiándolos de otros repositorios.
Mi máquina virtual se bloqueó durante la grabación de una confirmación de empuje, por lo que los objetos se almacenaron de forma segura en una computadora local. Los llamé a la máquina virtual y voila - git fsck no produce errores.
Simplemente elimine el objeto corrupto del que git se queja. Pude resolver el mismo problema ahora de esta manera.
fatal: object 985a4870e7d890b314d2794377045a8b007c7925 is corrupted
Para el error anterior, yo era capaz de encontrar el objeto que corresponde a:
project_directory/.git/objects/98/5a4870e7d890b314d2794377045a8b007c7925
donde se puede ver el archivo es de 0 bytes y eliminarlo permitió que el FETCH para empezar a trabajar.
Es de suponer que la recuperación anterior se interrumpió, dejando el objeto dañado con tamaño = 0 bytes.
extraño que esto realmente funcione, como patear el televisor para aclarar la estática! –
No funcionó para mí y suena como un mal idea teniendo en cuenta varias instrucciones de la página de Torvalds sobre cómo reparar el objeto corrupto (enumerados anteriormente en la respuesta). –
No funcionó para mí tampoco. Mi objeto
tenía el mismo problema, lo que comando git me encontré, terminó con el mensaje:
fatal: object <hash> is corrupted
no tenía una copia de seguridad y no quiero perder mis confirmaciones, así que decidí tratar la solución de Jase y eliminado el archivo 0 longitud que tenía: .git/objects/00/<hash> a continuación tiene la misma:
$ git status
fatal: bad object HEAD
Entonces, traté de saber lo que estaba mal y mirado en .git/refs/heads/master donde tuve el hash.
Miré en .git/logs/refs/head/master y encontraron líneas como ésta:
<old commit> <new commit> <author> <timestamp> commit: <commit message>
I retira la última línea (que tenía =) y pegado de esta línea en .git/refs/heads/master, borrando su contenido
yo era entonces capaz de comprometerse exitosamente
Tuve este mismo problema. Me di cuenta de que no estaba conectado como root. Cuando inicié sesión como root, pude verificar el registro sin el signo de error.
para solidificar esta en buenas condiciones, lo hice:
git add .
git commit -a -m "stabilize git"
que salía de la raíz e intentaron tirar de un cliente. Me funcionó después.
Cuando hice el agregar y confirmar, sabía que estaba bien con lo que estaba en el directorio. No tuve cambios visibles a través del "estado de git".
Debo añadir que la causa raíz de esto fue la corrupción del disco en mi máquina virtual, que no se cerró correctamente. – Keyo