tag - Reparar el repositorio git corrupto

git tag best practices

Question

Mi repositorio de git se corrompió después de un par de reinicios debido a problemas con el suministro de energía y ahora no puedo solucionarlo (estaba en el medio de la puesta en escena de algunos archivos en el último corte de energía)

$ git status                                                                                                                          
fatal: failed to read object 3d18855708b0f127d40c13c679559d7679228b69: Invalid argument
$ git fsck
fatal: failed to read object 24377c609184c192f3f3c1733bac7115c1080758: Invalid argument
$ git branch -a
(...works, lists branches...)
$ git checkout someotherbranch
fatal: failed to read object 3d18855708b0f127d40c13c679559d7679228b69: Invalid argument
$ git log                                              
fatal: failed to read object 3d18855708b0f127d40c13c679559d7679228b69: Invalid argument
$ git log someotherbranch
(...works, shows commits...)

Entonces, como pueden ver, mi rama actual está bastante jodida y parece que no puedo solucionarlo. Cualquier idea, ¿qué puedo tratar de reparar esto?

Answer 1

Esto me pasó a mí. Recoloco el repositorio en una nueva carpeta y muevo mis últimos cambios manualmente. Baja tecnología pero funciona todo el tiempo. Espero que puedas recordar tus últimos cambios.

Answer 2

Intente hacer una copia de seguridad del repositorio y luego ejecute git reset --hard HEAD@{1} para volver al HEAD anterior y ver si esto funciona. Puede ser solo la HEAD actual que está dañada.

(También debería ejecutar fsck en su disco si aún no lo ha hecho).

Answer 3

La solución más simple para mí: puedes clonar en una nueva carpeta, luego reemplazar la carpeta nueva / nueva limpia a la carpeta anterior (la carpeta rota). ¡Me funciona bien!

git clone ...(remote) new_folder
mv old_folder/.git  old_folder/.git_old
cp -R new_folder/.git  old_folder/

¡Aclamaciones!

Answer 4

Mi solución para una situación similar fue reemplazar un hash del objeto dañado en .git/refs/heads/my-working-branch con un hash de commit anterior (que se puede encontrar en .git/logs/HEAD ).

Answer 5

Otra alternativa que funcionó para mí fue restablecer el índice e cabeza de git a su estado anterior usando:

git reset --keep

También probé los siguientes comandos pero no me funcionaron, pero podrían ser para ti:

git reset --mixed git fsck --full git gc --auto git prune --expire now git reflog --all

Answer 6

Para mí, habilité TRIM en OSX con un SSD que no es de Apple (que no se recomienda) y aparentemente causó varias corrupciones en mi disco de arranque. Entonces el compromiso corrupto fue profundo en la historia.

No me importa demasiado reparar mi repositorio, excepto que tengo algunas sucursales locales que eran demasiado experimentales como para molestarme en enviar al repositorio remoto, y me gustaría salvar el trabajo en esas sucursales.

Teóricamente, como se trata de un repositorio local, creo que git debería poder recuperarse / repararse utilizando el origen. ¿Por qué no es esto posible?

En cualquier caso, me encontré con esta estrategia genial para llevar una sucursal a otro repositorio de git local. Lamentablemente, clonar el repositorio en ../repo_copy y luego usarlo como control remoto local dio como resultado el siguiente error:

! git push --force local_remote HEAD
fatal: failed to read object e0a9dffddeeca96dbaa275636f8e8f5d4866e0ed: Invalid argument
error: failed to push some refs to ''/Users/steve/Dev/repo_copy''

Así que comencé con un repositorio vacío, luego empujé ramas para que funcionara bien. Entonces, para cualquier sucursal local que tuve cuyo git log no terminó en:

....
    Fixing cukes
fatal: failed to read object e0a9dffddeeca96dbaa275636f8e8f5d4866e0ed: Invalid argument

Simplemente lo verificaría y luego haría git push --force local_remote HEAD . Lo último que hice fue:

! cd ~/Dev/repo_copy
! git remote add origin [email protected]:sdhull/my_repo.git  # real remote

Luego entré a git config -e y configuré mi rama principal y volví a funcionar sin perder nada. Déjame saber en los comentarios si quieres más detalles sobre este enfoque. ¡Aclamaciones!

Answer 7

Pude recuperar mi repo de:

zsh(broken)% git log master
error: object file .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395 is empty
error: object file .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395 is empty
fatal: loose object 7fcab8648a989d9bb3f5246e6be7220395493395 (stored in .git/objects/7f/cab8648a989d9bb3f5246e6be7220395493395) is corrupt
zsh(broken)% cat .git/refs/heads/master
7fcab8648a989d9bb3f5246e6be7220395493395
e311726c4eb970f4d4f504ad86248d322855018f da9c14d03e4849394087b61ff6272399937f7cce Nikolay Orliuk <[email protected]> 1379583764 +0300   commit: plan: timings

Al restablecer el master a la confirmación da9c14d03e4849394087b61ff6272399937f7cce , dicho por @Nash Bridges:

zsh(broken)% echo da9c14d03e4849394087b61ff6272399937f7cce > .git/refs/heads/master
zsh(broken)% git log --oneline -1 master
da9c14d plan: timings
zsh(broken)% git fsck
Checking object directories: 100% (256/256), done.
error: object file .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5 is empty
error: object file .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5 is empty
fatal: loose object 0eace931fdc851da254e9522596d1517d0ed51c5 (stored in .git/objects/0e/ace931fdc851da254e9522596d1517d0ed51c5) is corrupt

Creando nuevo repositorio vacío, obteniendo el master de los dañados

zsh(broken)% mkdir ../recover && cd ../recover && git init
Initialized empty Git repository in /home/nikolay/talks/y/recover/.git/
zsh(recover)% git fetch ../broken master
remote: Counting objects: 44, done.
remote: Compressing objects: 100% (44/44), done.
remote: Total 44 (delta 20), reused 0 (delta 0)
Unpacking objects: 100% (44/44), done.
From ../broken
 * branch            master     -> FETCH_HEAD
zsh(recover)% git reset --hard FETCH_HEAD
HEAD is now at da9c14d plan: timings
zsh% git fsck
Checking object directories: 100% (256/256), done.

Para restaurar esos cambios que estaban en camino de master :

zsh(recover)% rm -rf * && cp -a ../broken/* ./          
zsh(recover)% git add -u && git commit -m ''prepare for publishing''

Answer 8

Seguí las instrucciones que se encuentran here

$ cd /tmp/
$ git clone good-host:/path/to/good-repo
$ cd /home/user/broken-repo
$ echo /tmp/good-repo/.git/objects/ > .git/objects/info/alternates
$ git repack -a -d
$ rm -rf /tmp/good-repo

Trabajó para mi

Answer 9

Tuve el mismo problema e hice los siguientes pasos usando git-repair.branchable.com

• cp myrepro myrepro.bak
• cd myrepro
• git repair --force (primero pruébalo sin force ) Después de que esto fue exitoso, el árbol se regresó a la última confirmación de trabajo.

Luego meld myrepro myrepro.bak para aplicar cambios del árbol de trabajo de la reproducción corrupta a la reprografía fija.