Git: “Objeto suelto corrupto”

11 minutos de lectura

Git Objeto suelto corrupto
asgerhallas

Cada vez que saco de mi control remoto, aparece el siguiente error sobre la compresión. Cuando ejecuto la compresión manual, obtengo lo mismo:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

¿Alguien sabe qué hacer al respecto?

De cat-file obtengo esto:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

Y de git fsck obtengo esto (no sé si realmente está relacionado):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

¿Alguien puede ayudarme a descifrar esto?

  • ¿Ha intentado mirar el último objeto (45ba4ceb93bc812ef20a6630bb27e9e0b33a012a)?

    – Gintautas Miliauskas

    23 de noviembre de 2010 a las 13:56

  • Gracias… pero ¿cómo se “mira” un objeto? Todavía nuevo en git 🙂

    – asgerhallas

    23 de noviembre de 2010 a las 14:23

  • ‘git show’ no me da nada más que ‘git fsck’ desafortunadamente.

    – asgerhallas

    26 de noviembre de 2010 a las 14:40

  • Linus Torvalds escribió el siguiente documento útil sobre este error y cómo reconstruir manualmente los blobs si tiene los archivos: Cómo recuperar un objeto blob dañado Algunos trucos para reconstruir objetos blob con el fin de reparar un repositorio corrupto

    – Uwe Kleine-König

    19 de mayo de 2011 a las 8:35


  • ¿Puede agregar algunos comentarios o editar la respuesta aceptada? Estoy exactamente en la misma situación, y la respuesta aceptada no parece contener suficientes detalles para “Just Work TM”, sino que me obligará a sumergirme en los detalles yo mismo.

    – destripador234

    20 de febrero de 2012 a las 21:37

Git Objeto suelto corrupto
lechuga cubica

Tuve el mismo problema (no sé por qué).

Esta solución requiere acceso a una copia remota no corrupta del repositorio y mantendrá intacta su copia de trabajo local.

Pero tiene algunos inconvenientes:

  • Perderá el registro de todas las confirmaciones que no se enviaron y tendrá que volver a confirmarlas.
  • Perderás cualquier escondite.

La solución

Ejecute estos comandos desde el directorio principal sobre su repositorio (reemplace ‘foo’ con el nombre de la carpeta de su proyecto):

  1. Cree una copia de seguridad del directorio corrupto:
    cp -R foo foo-backup
  2. Haga un nuevo clon del repositorio remoto en un nuevo directorio:
    git clone git@www.mydomain.de:foo foo-newclone
  3. Elimine el subdirectorio .git corrupto:
    rm -rf foo/.git
  4. Mueva el subdirectorio .git recién clonado a foo:
    mv foo-newclone/.git foo
  5. Elimine el resto del nuevo clon temporal:
    rm -rf foo-newclone

En Windows necesitará usar:

  • copy en lugar de cp -R
  • rmdir /S en lugar de rm -rf
  • move en lugar de mv

Ahora foo tiene su original .git subdirectorio atrás, pero todos los cambios locales todavía están allí. git status, commit, pull, pushetc. funcionan de nuevo como deberían.

  • Este método funcionó para mi. Sin embargo, creo que se perdieron todas las confirmaciones no enviadas. Los datos del repositorio no se tocaron.

    – wontón

    11 de febrero de 2013 a las 23:46


  • Sí, la información de confirmación no insertada se perderá. Pero en escenarios comunes (no hay múltiples sucursales locales con cambios no enviados en otros que no sean el actual), todas las modificaciones de archivos más recientes (eliminaciones de tinta) todavía están en el disco, por lo tanto, uno puede repetir fácilmente cualquier confirmación previa no enviada. Dado que siempre presiono después de cualquier secuencia de confirmaciones, ni siquiera me encontré con este problema.

    – lechuga cúbica

    20 de febrero de 2013 a las 9:19

  • Simple y directo. Esta es, en mi opinión, la solución más eficiente si no entiende todo sobre git y no quiere jugar con su repositorio.

    – Oliboy50

    11 de junio de 2014 a las 12:54

  • Creo que eliminaría todos los escondites ya que están almacenados en el subdirectorio .git.

    –Anthony Elliott

    31 de julio de 2014 a las 16:25

  • En caso de que haya submódulos en el proyecto, es necesario iniciarlos antes de recuperar el .git carpeta.

    – AdrianKhisbe

    26 de agosto de 2014 a las 7:59

1646968391 48 Git Objeto suelto corrupto
usuario1055643

Su mejor apuesta es probablemente volver a clonar desde el repositorio remoto (es decir, GitHub u otro). Desafortunadamente, perderá las confirmaciones no enviadas y los cambios ocultos; sin embargo, su copia de trabajo debe permanecer intacta.

Primero haga una copia de seguridad de sus archivos locales. Luego haz esto desde la raíz de tu árbol de trabajo:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master

Luego confirme los archivos modificados según sea necesario.

  • En mi humilde opinión, esta debería ser la respuesta aceptada. ¡Mucho más fácil que eliminar el repositorio y volver a clonarlo! 🙂 Aunque pierdes cualquier confirmación por etapas…

    – Nick

    22 de enero de 2015 a las 14:43

  • Obviamente, si estaba en una rama que no sea maestra cuando ocurrió la corrupción, reemplace master con el nombre de tu sucursal.

    – Timoteo Zorn

    9 de febrero de 2017 a las 23:33

  • Principalmente funcionó como está, pero estaba en otra rama working cuando se corrompió y estos pasos no me dieron una copia local de ninguna rama que no sea master (y sí, intenté reemplazar master arriba con working pero eso no funcionó). Terminé haciendo los pasos anteriores con masterluego guardar mis cambios y hacer checkout -b working origin/working y haciendo estallar el alijo allí. Parece haber funcionado, ¡gracias!

    – fantabuloso

    16 de diciembre de 2017 a las 5:13


  • Mi repositorio tenía un submódulo que no estaba dañado. Este proceso dejó el repositorio y su submódulo en un estado en el que comandos como git status cedido fatal: Not a git repository: submodules/my-sub/../../.git/modules/my-sub. Eliminar el submódulo del sistema de archivos y reiniciar el proceso restauró la normalidad. Probablemente asegurarse de que no haya conjuntos de cambios no insertados en los submódulos primero sea una buena idea …

    – Steven Baldasty

    22 de febrero de 2018 a las 20:43

  • Hice esto hoy y no perdí los cambios no confirmados en los archivos 🙂 (git 2.17.1)

    – Fabio Dias

    12 de junio de 2018 a las 18:03

Trabajando en una VM, en mi computadora portátil, la batería se agotó, obtuve este error;

error: el archivo de objeto .git/objects/ce/theRef está vacío error: el archivo de objeto .git/objects/ce/theRef está vacío fatal: el objeto suelto theRef (almacenado en .git/objects/ce/theRef) está corrupto

Logré que el repositorio volviera a funcionar con solo 2 comandos y sin perder mi trabajo (archivos modificados/cambios no confirmados)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

Después de eso, ejecuté un git statusel repositorio estaba bien y estaban mis cambios (esperando ser confirmados, hágalo ahora).

git versión 1.9.1

Recuerde hacer una copia de seguridad de todos los cambios que recuerde, en caso de que esta solución no funcione y se necesite un enfoque más radical.

  • find .git/objects/ -size 0 -exec rm -f {} \; funciona para mi 😉

    – Lázaro Fernández Lima Suleiman

    2 de febrero de 2017 a las 19:25

  • Tuve el mismo problema, ejecuté el comando, funcionó perfectamente para mí en Mint VM.

    – Ludvig Rydahl

    5 de mayo de 2017 a las 14:09

  • No en una máquina virtual y esto me ha funcionado muchas veces. IDK por qué esto sigue sucediendo en mi proyecto actual, pero esto lo soluciona todo el tiempo.

    – James L.

    4 oct 2017 a las 22:09

  • Es posible que deba ejecutar git symbolic-ref HEAD refs/heads/master. después de eliminar los objetos vacíos.

    – Stephan

    19 de noviembre de 2017 a las 18:29

  • podría sugerir find .git/objects/ -empty -delete

    – CervEd

    25 de abril de 2021 a las 10:49

1646968392 653 Git Objeto suelto corrupto
adam dimitruk

Parece que tienes un objeto de árbol corrupto. Necesitarás obtener ese objeto de otra persona. Esperemos que tengan una versión no corrupta.

De hecho, podría reconstruirlo si no puede encontrar una versión válida de otra persona adivinando qué archivos deberían estar allí. Es posible que desee ver si las fechas y horas de los objetos coinciden. Esos podrían ser los blobs relacionados. Podría inferir la estructura del objeto de árbol a partir de esos objetos.

Echa un vistazo a Capturas de pantalla Git de Scott Chacon con respecto a las partes internas de git. Esto le mostrará cómo funciona git bajo el capó y cómo hacer este trabajo de detective si está realmente atascado y no puede obtener ese objeto de otra persona.

1646968392 377 Git Objeto suelto corrupto
declan

Mi computadora se bloqueó mientras estaba escribiendo un mensaje de confirmación. Después de reiniciar, el árbol de trabajo estaba como lo había dejado y pude confirmar con éxito mis cambios.

Sin embargo, cuando intenté correr git status tengo

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

A diferencia de la mayoría de las otras respuestas, no estaba tratando de recuperar ningún dato.. Solo necesitaba que Git dejara de quejarse del archivo de objeto vacío.

Visión de conjunto

El “archivo de objeto” es la representación hash de Git de un archivo real que le interesa. Git cree que debería tener una versión hash de some/file.whatever guardado en .git/object/xx/12345y corregir el error resultó ser principalmente una cuestión de averiguar qué archivo se suponía que representaba el “objeto suelto”.

Detalles

Las opciones posibles parecían ser

  1. Eliminar el archivo vacío
  2. Obtener el archivo en un estado aceptable para Git

Enfoque 1: eliminar el archivo de objeto

Lo primero que intenté fue simplemente mover el archivo de objeto

mv .git/objects/xx/12345 ..

Eso no funcionó: Git comenzó a quejarse de un enlace roto. Hacia el Acceso 2.

Enfoque 2: arreglar el archivo

Linus Torvalds tiene una gran reseña de cómo recuperar un archivo de objeto eso resolvió el problema para mí. Los pasos clave se resumen aquí.

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345    your_file.whatever

Esto le dice de qué archivo se supone que el objeto vacío es un hash. Ahora puedes repararlo.

$> git hash-object -w path/to/your_file.whatever

Después de hacer esto comprobé .git/objects/xx/12345ya no estaba vacío y Git dejó de quejarse.

  • Estaba en una situación en la que no tenía ningún control remoto o copia de seguridad de mi repositorio, y donde el objeto dañado se agregó cerca de la confirmación inicial, probablemente corrompiendo todo el árbol de todos modos. Tuve mi propio camino tratando de recrear el objeto en un repositorio diferente, pero esta respuesta logra el mismo resultado con más delicadeza.

    – Estecka

    14 dic 2019 a las 15:31


  • no funciona para mi yo obtengo error: object file .git/objects/af/c1e62b3ff4f76d034551fa5c6131635a83434f is empty pero estos archivos faltan y git fsck no enumera ningún enlace roto.

    – reinierpost

    1 de septiembre de 2021 a las 11:22


  • Elimine el archivo dañado manualmente y luego haga git pull. Solucionará el problema.

    – Iftikhar Ali Ansari

    13 de septiembre de 2021 a las 10:07

1646968392 898 Git Objeto suelto corrupto
Arturo

Tratar

git stash

Esto funcionó para mí. Guarda todo lo que no hayas cometido y eso resolvió el problema.

  • Estaba en una situación en la que no tenía ningún control remoto o copia de seguridad de mi repositorio, y donde el objeto dañado se agregó cerca de la confirmación inicial, probablemente corrompiendo todo el árbol de todos modos. Tuve mi propio camino tratando de recrear el objeto en un repositorio diferente, pero esta respuesta logra el mismo resultado con más delicadeza.

    – Estecka

    14 dic 2019 a las 15:31


  • no funciona para mi yo obtengo error: object file .git/objects/af/c1e62b3ff4f76d034551fa5c6131635a83434f is empty pero estos archivos faltan y git fsck no enumera ningún enlace roto.

    – reinierpost

    1 de septiembre de 2021 a las 11:22


  • Elimine el archivo dañado manualmente y luego haga git pull. Solucionará el problema.

    – Iftikhar Ali Ansari

    13 de septiembre de 2021 a las 10:07

1646968393 640 Git Objeto suelto corrupto
Pedro Mortensen

A recolección de basura solucionado mi problema:

git gc --aggressive --prune=now

Tarda un poco en completarse, pero se repararon todos los objetos sueltos y/o índices corruptos.

  • Esta es una buena solución. Trabajó para mi. Mi sistema se apagó accidentalmente. Sin embargo, este comando me salvó de la clonación y todas esas tareas pesadas. Gracias Jago.

    – Mukesh Kumar

    16 de agosto de 2017 a las 13:05

  • “no se pudo ejecutar reflog”

    – Vladimir Brasil

    13 de febrero de 2020 a las 12:29

  • De otra pregunta: “Solamente utilizando git gc --prune=now no funcionará ya que todavía se hace referencia a esas confirmaciones en el registro de referencia. Por lo tanto, borrar el registro de referencia es obligatorio”.

    -Peter Mortensen

    29 de agosto de 2021 a las 18:48


¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad