source - Git: "Objeto suelto corrupto"

git login (21)

Acabamos de tener el caso aquí. Sucedió que el problema era que la propiedad del archivo dañado era root en lugar de nuestro usuario normal. Esto fue causado por una confirmación realizada en el servidor después de que alguien haya hecho un "sudo su -".

Primero, identifica tu archivo corrupto con:

$> git fsck --full

Deberías recibir una respuesta como esta:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Ve a la carpeta donde está el archivo corrupto y haz un:

$> ls -la

Compruebe la propiedad del archivo corrupto. Si eso es diferente, simplemente vuelve a la raíz de tu repositorio y haz un:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

¡Espero eso ayude!

Cada vez que extraigo el 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 está realmente 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?

Acabo de experimentar esto: mi máquina se estrelló al escribir en el repositorio de Git y se corrompió. Lo arreglé como sigue.

Comencé observando cuántas confirmaciones no había enviado al repositorio remoto, por lo tanto:

gitk &

Si no utiliza esta herramienta, es muy útil: está disponible en todos los sistemas operativos, que yo sepa. Esto indicaba que faltaban dos confirmaciones en mi control remoto. Por lo tanto, hice clic en la etiqueta que indica la última confirmación remota (por lo general, será /remotes/origin/master ) para obtener el hash (el hash tiene una longitud de 40 caracteres, pero para ser breve, estoy usando 10 aquí, esto generalmente funciona de todos modos).

Aquí está:

14c0fcc9b3

Luego hago clic en la siguiente confirmación (es decir, la primera que el control remoto no tiene) y obtengo el hash allí:

04d44c3298

Luego uso ambos para hacer un parche para este commit:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Luego hice lo mismo con el otro commit faltante, es decir, usé el hash del commit anterior y el hash del commit mismo:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Luego me mudé a un nuevo directorio, cloné el repositorio desde el control remoto:

git clone [email protected]:username/repo.git

Luego moví los archivos de parche a la nueva carpeta, los apliqué y los gitk con sus mensajes de confirmación exactos (se pueden pegar desde el git log o la ventana de gitk ):

patch -p1 < 1.patch git commit patch -p1 < 2.patch git commit

Esto me devolvió las cosas (y tenga en cuenta que probablemente haya una forma más rápida de hacerlo para un gran número de confirmaciones). Sin embargo, tenía ganas de ver si el árbol en el repositorio dañado puede repararse, y la respuesta es que sí. Con un repositorio reparado disponible como anteriormente, ejecute este comando en la carpeta rota:

git fsck

Obtendrá algo como esto:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Para hacer la reparación, haría esto en la carpeta rota:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

es decir, eliminar el archivo dañado y reemplazarlo por uno bueno. Tu debes hacer esto varias veces. Finalmente, habrá un punto en el que puede ejecutar fsck sin errores. Es probable que tenga líneas de "confirmación colgante" y "burbuja colgante" en el informe, estas son consecuencia de sus cambios y enmiendas en esta carpeta, y están bien. El recolector de basura los eliminará a su debido tiempo.

Por lo tanto (al menos en mi caso) un árbol dañado no significa que las confirmaciones no presionadas se pierdan.

Acabo de tener un problema como este. Mi problema en particular fue causado por una falla del sistema que dañó la confirmación más reciente (y por lo tanto también la rama maestra). No había presionado, y quería volver a hacer ese compromiso. En mi caso particular, pude manejarlo así:

Haga una copia de seguridad de .git/ : rsync -a .git/ git-bak/
Verifique .git/logs/HEAD y busque la última línea con un ID de confirmación válido. Para mí, este fue el segundo commit más reciente. Esto fue bueno, porque todavía tenía las versiones de directorio de trabajo del archivo, y así todas las versiones que quería.
Haga una rama en ese commit: git branch temp <commit-id>
volver a hacer la confirmación rota con los archivos en el directorio de trabajo.
git reset master temp para mover la rama maestra a la nueva confirmación que realizó en el paso 2.
git checkout master y comprueba que se ve bien con git log .
git branch -d temp .
git fsck --full , y ahora debería ser seguro eliminar cualquier objeto dañado que encuentre fsck.
Si todo se ve bien, intente empujar. Si eso funciona,

Eso funcionó para mí. Sospecho que este es un escenario bastante común, ya que el compromiso más reciente es el más probable de que se corrompa, pero si pierde uno más atrás, probablemente aún pueda usar un método como este, con un uso cuidadoso de git cherrypick , y El reflog en .git/logs/HEAD .

Cuando tuve este problema, hice una copia de seguridad de mis cambios recientes (ya que sabía lo que había cambiado) y luego eliminé el archivo del que se quejaba en .git / location. Entonces hice un tirón git. Tenga cuidado, sin embargo, esto podría no funcionar para usted.

En respuesta a @ user1055643 falta el último paso:

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

Mi computadora falló cuando estaba escribiendo un mensaje de confirmación. Después de reiniciar, el árbol de trabajo estaba como lo había dejado y pude confirmar correctamente mis cambios.

Sin embargo, cuando intenté ejecutar el git status obtuve

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 intentando recuperar ningún dato . Solo necesitaba que Git dejara de quejarse por el archivo de objeto vacío.

Visión general

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 con hash de some/file.whatever almacenado en .git/object/xx/12345 , y corregir el error resultó ser principalmente una cuestión de averiguar qué archivo se suponía que representaba el "objeto suelto" .

Detalles

Posibles opciones parecían ser

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

Enfoque 1: eliminar el archivo objeto

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

mv .git/objects/xx/12345 ..

Eso no funcionó - git comenzó a quejarse de un enlace roto. En el Enfoque 2.

Enfoque 2: arreglar el archivo

Linus Torvalds tiene una gran reseña de cómo recuperar un archivo de objeto que 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 indica de qué archivo se supone que es un hash el objeto vacío. Ahora puedes repararlo.

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

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

Para mí, esto sucedió debido a un corte de energía al hacer un git push .

Los mensajes se veían así:

$ git status error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Intenté cosas como git fsck pero eso no ayudó. Dado que el bloqueo ocurrió durante un git push , obviamente ocurrió durante la reescritura en el lado del cliente, lo que sucede después de que se actualiza el servidor. Miré a mi alrededor y calculé que c2388 en mi caso era un objeto de confirmación, porque se mencionaba en las entradas en .git/refs . Entonces supe que podría encontrar c2388 cuando mirara el historial (a través de una interfaz web o un segundo clon).

En el segundo clon hice un git log -n 2 c2388 para identificar al predecesor de c2388 . Luego modifiqué manualmente .git/refs/heads/master y .git/refs/remotes/origin/master para ser el antecesor de c2388 lugar de c2388 . Entonces podría hacer un git fetch . El git fetch falló varias veces por conflictos en objetos vacíos. Quité cada uno de estos objetos vacíos hasta que git fetch tuvo éxito. Eso ha curado el repositorio.

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

Realmente 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.

Eche un vistazo a Git Screencasts de Scott Chacon con respecto a los internos 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.

Probablemente, su mejor apuesta es simplemente volver a clonar desde el repositorio remoto (es decir, Github u otro). Desafortunadamente, perderá cualquier confirmación no introducida y cambios ocultos, sin embargo, su copia de trabajo debe permanecer intacta.

Primero haga una copia de respaldo de sus archivos locales. Entonces 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

A continuación, confirme los archivos modificados según sea necesario.

Recibí este error después de que mi máquina (Windows) decidiera reiniciarse. Afortunadamente, mi control remoto estaba actualizado, así que acabo de hacer un git-clone nuevo.

Resolví de esta manera: decidí simplemente copiar el archivo de objeto no dañado del clon de la copia de seguridad a mi repositorio original. Esto funcionó igual de bien. (Por cierto: si no puede encontrar el objeto en .git / objects / por su nombre, probablemente haya sido [empaquetado] [paquete] para ahorrar espacio.)

Runnning git stash; git stash pop git stash; git stash pop solucionó mi problema

Seguí muchos de los otros pasos aquí; La descripción de Linus de cómo mirar el árbol / objetos git y encontrar lo que falta fue especialmente útil. git-git recuperar blob dañado

Pero al final, para mí, tuve objetos de árbol sueltos / corruptos causados por una falla parcial del disco, y los objetos de árbol no se recuperan tan fácilmente / no están cubiertos por ese documento.

Al final, aparté los objects/<ha>/<hash> conflicto objects/<ha>/<hash> , y usé git unpack-objects con un paquete de archivos de un clon razonablemente actualizado. Fue capaz de restaurar los objetos del árbol que faltan.

Todavía me dejó con muchas manchas colgantes, lo que puede ser un efecto secundario de desempacar cosas previamente archivadas, y se abordó en otras preguntas here

Simplemente elimina la carpeta .git y agrégala de nuevo. Esta solución simple funcionó para mí.

También estaba recibiendo un error de objeto perdido corrupto.

./objects/x/x

Lo arreglé exitosamente entrando en el directorio del objeto corrupto. Vi que los usuarios asignados a ese objeto no eran los de mi git. No sé cómo sucedió, pero ejecuté un chown git:git en ese archivo y luego funcionó de nuevo.

Esto puede ser una solución potencial para los problemas de algunas personas, pero no es necesario para todos ellos.

Trabajando en una máquina virtual, en mi cuaderno, la batería se agotó, se produjo 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á dañado.

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 status , el repositorio estaba bien y estaban mis cambios (en espera de ser confirmados, hazlo ahora ...).

git version 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.

Tratar

git stash

Esto funcionó para mí. Guarda cualquier cosa que no hayas cometido y que solucionó el problema.

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

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

Pero tiene algunos inconvenientes:

Perderá el registro de cualquier confirmación que no haya sido empujado, y tendrá que volver a comprometerse.
Perderás cualquier escondite.

La solución

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

Crear una copia de seguridad del directorio corrupto:
cp -R foo foo-backup
Haga un nuevo clon del repositorio remoto a un nuevo directorio:
git clone [email protected]:foo foo-newclone
Elimine el subdirectorio corrupto .git:
rm -rf foo/.git
Mueva el subdirectorio .git recién clonado a foo:
mv foo-newclone/.git foo
Eliminar el resto del nuevo clon temporal:
rm -rf foo-newclone

En Windows necesitarás usar:

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

Ahora foo ha recuperado su subdirectorio .git original, pero todos los cambios locales todavía están allí. git status , commit , pull , push , etc. funcionan de nuevo como deberían.

Tuve este mismo problema en mi remoto repositorio de git. Después de solucionar muchos problemas, descubrí que uno de mis compañeros de trabajo había realizado una confirmación en la que algunos archivos de .git / objects tenían permisos de 440 (r - r -----) en lugar de 444 (r - r - r -). Después de pedirle al compañero de trabajo que cambiara los permisos con "chmod 444 -R objetos" dentro del repositorio de git, el problema se solucionó.

Una recolección de basura solucionó mi problema:

git gc --aggressive --prune=now

Tarda un poco en completarse, pero se corrigieron todos los objetos sueltos y / o el índice dañado.

simplemente ejecutando un git prune solucionado este problema para mí