¿Cómo lidiar con este error git

Question

estoy recibiendo este error en mi repositorio git:

22:09:15 $ git status 
# On branch master 
error: Could not read 8124cc15c63be92d534e4cdfa33c38d54deee122 
error: unable to read tree object HEAD 
nothing to commit (working directory clean) 

Una búsqueda en Google de error: unable to read tree object HEAD no da lugar a mucha ayuda, este error parece ser muy raro. No estoy seguro de cómo lidiar con eso. ¿Podría ser una falla en el disco duro?

Editar: La salida de git fsck es la siguiente:

broken link from commit 607328dc80e4901a55b95c683d4fbf43e6df28bf 
       to tree 8124cc15c63be92d534e4cdfa33c38d54deee122 
missing tree 8124cc15c63be92d534e4cdfa33c38d54deee122 
dangling tree 56b5d4a5e429d251582ec927bca7ef1225510c41 
dangling tree 0259d2d38b18b6136bb6070fb41faf3624453cc6 

Answer 1

En un mensaje de "enlace roto", se podía seguir el GitFaq recommendations:

• copia de seguridad de todos sus estado para que todo lo que hagas sea posible de nuevo si corrompes las cosas más.
• explotar cualquier paquete de archivos corruptos
  • Ver "man git-unpack-objects", y en particular la "-r" bandera.
    Además, tenga en cuenta que solo desempaqueta objetos que aún no están disponibles, por lo que primero debe mover el archivo del paquete fuera de su ubicación normal (de lo contrario, git-unpack-objects encontrará todos los objetos que están en el paquete del archivo del paquete -FILE sí mismo, y no desempaquetar nada en absoluto)
• reemplazar los objetos rotos y/o faltantes
  • Esta es la parte difícil.
    A veces (¡con suerte!) Puede encontrar los objetos faltantes en otras copias de los repositorios.
    En otras ocasiones, es posible que deba intentar buscar los datos de otra forma (por ejemplo, ¿tal vez su copia comprobada contiene el contenido del archivo que cuando hashed será el objeto faltante?).
• asegurarse de que todo está contento con "git fsck --full"
• rehacer todo para volver a un estado eficiente de nuevo

---

Notas:

• objetos que faltan pueden también sea related to alternate (cuando share objects between repositories) wi th git alternates (aunque ese can be risky).
• El complemento JGit/Egit eclipse también se conoce como have a few issues.
  (Actualización de febrero de 2012: those plugins han recorrido un largo camino y ahora son bastante estables)

actualización de julio de 2016 (7 años los laters), con Git 2.10 que pronto será liberado, ahora tiene:

git fsck --name-objects 

Ayuda a nombrar el origen de esos enlaces rotos

Ver "How to fix git error broken link from tree to tree?" por más.

Answer 2

Tuve el mismo problema. Después de mucho tirón de pelo, descubrí que se debía a un cambio de permiso en los archivos git del repositorio. Lo he resuelto de la siguiente manera:

$ cd .git 
$ chmod 755 * 

¡Hecho!

Answer 3

Tuve un problema similar en este momento. La corrupción surgió cuando mi computadora portátil se apagó duramente durante un git pull. Tengo un repositorio de copia de seguridad remota. Primero tuve varios archivos de objetos en .git/objects/??/* que eran de tamaño cero. Después de una copia de seguridad cp -a del repositorio, hice esto:

• eliminar la longitud cero objetos
• clon el repositorio remoto en un ../fresh/ repositorio

• en el repositorio roto, lo hice

  cat ../fresh/.git/objects/pack/pack-*.pack | git unpack-objects

Esto llenó los objetos faltantes en el base de datos de objetos. El repositorio parece estar copia de seguridad ahora.

Answer 4

Si usted no tiene cambios ni comprometer la solución más fácil es eliminar la rama local: [-b rama git checkout: git branch [nombre de la sucursal]

y luego pago una vez más la rama remota -D nombre] origen/[nombre de la sucursal]

Answer 5

Recibí un error similar en el repositorio Git de mi instalación Homebrew. En lugar de restaurar todos los objetos faltantes uno por uno, me resultó más fácil simplemente eliminar el directorio .git y volver a crearlo volviendo a clonar desde Homebrew’s public repository. Estos fueron mis pasos:

• Compruebe qué información tiene en su repositorio de Git que no obtendrá con solo volver a clonar. Para mí, se trataba de ramas privadas, escondites y controles remotos.
  • Convierta stashes en commits reales creando una nueva rama, aplicando el alijo, y cometiendo algo así como "[WIP]" en el nombre para mostrar que es un alijo.
  • Guarde las ramas que no están en el control remoto público empujándolas a un control remoto propio. Esto podría ser una bifurcación del repositorio en GitHub, o simplemente un nuevo repositorio de Git en una ubicación diferente en su máquina.
  • Si tiene más de un control remoto, guarde la salida git remote -v, que contiene los nombres y las direcciones URL de sus controles remotos, para que pueda agregarlos manualmente más tarde.
• Eliminar el directorio de su repoistory .git (o cambie su nombre por .git-broken y eliminarlo después). En la línea de comandos, esto es rm -rf .git.
• Vuelva a clonar el directorio remoto con git clone https://github.com/Homebrew/homebrew.git o cualquier URI.
• Esto creará una nueva subcarpeta homebrew nombrada después del repositorio. Solo quiere el directorio .git; sus archivos locales ya están bien. Entonces mv homebrew/.git .git, y luego borre la carpeta homebrew.
• Su repositorio de Git no debería contener ningún error, ya que lo recreó desde el principio. Ahora solo restaure la información que guardó en el primer paso.
  • Si tiene controles remotos adicionales, agréguelos nuevamente con git remote add <name> <url>.
  • Si realizó una copia de seguridad de las ramas (o depósitos convertidos en ramas) en un repositorio remoto, extráigalos de ese repositorio a su repositorio local.
  • Si lo desea, puede convertir los stash-branches en stashes al pasar la confirmación "[WIP]" con git reset HEAD^ y guardar el directorio de trabajo en un alijo nuevamente con git stash save <custom-message>.

Si ejecuta git fsck, debería ver ningún error:

$ git fsck 
Checking object directories: 100% (256/256), done. 
Checking objects: 100% (197135/197135), done. 
Checking connectivity: 197162, done. 
$ 

Y git stash list, git branch y git remote -v deberían mostrar el mismo resultado que antes.

Answer 6

He arreglado el error al hacer cambios en la misma carpeta del directorio/proyecto y luego trataron de cometer el nuevo cambio, lo que pasó es que me dieron 'objeto no válido 100644 e38e910ceb18b09f436f353c3a131bfe2caba130 de' un error msg libro/alise_mathe/app/src/main/res/menu/drawermenu.xml ' este msg resolvió el problema, acabo de refactorizar el archivo drawermenu.xml cambiando el nombre del archivo a' drawer_menu.xml '. agregó los cambios cometidos y eso es todo. (Android-estudio)

Espero que esto ayude de alguna forma

Answer 7

me fijo este error mediante la supresión de la carpeta de Capistrano 'repo' de mi directorio del servidor remoto. Revisé varios de los otros problemas sugeridos y resolví que el problema no estaba en mi proyecto local. El problema parecía ocurrir cuando Capistrano estaba ejecutando tirando del repositorio al control remoto. Para mí, esto se debió quizás a una implementación detenida que dejó objetos dañados/referencias a objetos. Mi host también acaba de hacer una migración de servidor, tal vez algo se corrompió durante este proceso.