Reparar el repositorio git dañado

Mi repositorio git se corrompió después de un par de reinicios debido a problemas con el suministro de energía y ahora no puedo repararlo (estaba en el medio de algunos archivos en el último apagón)Reparar el repositorio git dañado

$ 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...)

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

Fuente

2011-11-25 Unknown

es esta cesión temporal del servidor? ¿existen clones/repos locales que pueda usar para la restauración? – prusswan

Es mi repositorio local de git ... Tengo un clon en otra máquina que podría usar para restaurar todo (con algunos commits perdidos quizás), pero prefiero arreglar este repositorio si es posible ... – Unknown

Vale la pena mencionar que el contenido de la carpeta de trabajo todavía puede ser recuperable. Haga 'git diff> diff.patch', luego podría usarlo para parchar un nuevo clon:' git patch -p1 datashaman

Intente hacer una copia de seguridad del repositorio y luego ejecutar git reset --hard [email protected]{1} para volver al HEAD anterior y ver si esto funciona. Puede ser solo el actual HEAD que está dañado.

(También debe ejecutar fsck en el disco si no lo ha hecho.)

Fuente

2011-11-25 15:39:51

$ git reset --hard HEAD @ {1} Comprobación de archivos: 100% (5724/5724), hecho. fatal: no se pudo leer el objeto 3d18855708b0f127d40c13c679559d7679228b69: argumento inválido – Unknown

maldito. ¿Funciona 'git reflog'? –

No, lo mismo :($ git reflog fatal: No se pudo leer objeto 3d18855708b0f127d40c13c679559d7679228b69: argumento no válido – Unknown

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

Fuente

2011-12-23 12:55:47

Aún deja el repositorio en estado roto, pero esto permite recuperarlo. – ony

No estoy seguro de entender lo que es –

wow. esto funciona ... mi 'HEAD' se había corrompido a'^@^@^@^@ ... 'o algo así. –

Para mí, había habilitado 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 preocupo demasiado por la reparación de 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 this cool strategy to push a branch to another local git repo. Por desgracia, la clonación de la cesión temporal en ../repo_copy y luego usar eso como un 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 empecé lugar con un repo vacío, luego empujando las ramas funcionaban bien. Así que para cualquier rama local que tenía cuya git log no terminó en:

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

simplemente me gustaría comprobarlo y luego hacer 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

Entonces fui a git config -e y la configuración de mi rama principal y era volver a funcionar sin nada perdido! Déjame saber en los comentarios si quieres más detalles sobre este enfoque. ¡Aclamaciones!

Fuente

2012-01-02 22:59:55 steve

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.

Fuente

2012-10-31 03:37:21 nbushnell

Simplemente puede reemplazar la carpeta '.git' en el repositorio roto con el que volvió a clonar. De esta forma, no necesita mover sus cambios manualmente. Solo tenga en cuenta la ramificación. Es posible que tengas que esconder y verificar la rama correcta. –

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 master a cometer prev da9c14d03e4849394087b61ff6272399937f7cce según lo dicho por @Nash Puentes:

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

Crear nueva operación vacía, ir a buscar master de roto

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.

Restaurar los thos e cambios que estaba en el camino a master:

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

Fuente

2013-09-21 03:43:43 ony

que siguieron 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

a mí me funcionó

Fuente

2017-01-10 11:46:18 MrJ

La solución más simple para mí: Usted podría git clone en una nueva carpeta, luego reemplace la carpeta new_folder/.git 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/

¡Salud!

Fuente

2017-04-21 08:44:28

Otra alternativa, que trabajó para mí era restablecer la cabeza git y el índice a su estado anterior usando:

git reset --keep

También probé los siguientes comandos pero no funcionó para mí, pero podría para usted:

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

Fuente

2017-07-07 15:57:26 gaborous

Reparar el repositorio git dañado

Respuesta

Cuestiones relacionadas