Pruebe los siguientes comandos al principio (vuelva a ejecutarlos si es necesario):
$ git fsck --full
$ git gc
$ git gc --prune=today
$ git fetch --all
$ git pull --rebase
Y luego todavía tienes los problemas, intenta:
eliminar todos los objetos corruptos, por ejemplo
fatal: loose object 91c5...51e5 (stored in .git/objects/06/91c5...51e5) is corrupt
$ rm -v .git/objects/06/91c5...51e5
eliminar todos los objetos vacíos, p. ej.
error: object file .git/objects/06/91c5...51e5 is empty
$ find .git/objects/ -size 0 -exec rm -vf "{}" \;
verifique un mensaje de "enlace roto" mediante:
git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
¡Esto le dirá de qué archivo vino el blob corrupto!
para recuperar el archivo, es posible que tenga mucha suerte, y puede ser la versión que ya ha verificado en su árbol de trabajo:
git hash-object -w my-magic-file
nuevamente, y si genera el SHA1 faltante (4b945 ..) ¡ya está listo!
asumiendo que era una versión anterior que estaba rota, la forma más fácil de hacerlo es hacer:
git log --raw --all --full-history -- subdirectory/my-magic-file
y eso le mostrará el registro completo para ese archivo (tenga en cuenta que el árbol que tenía puede no ser el árbol de nivel superior, por lo que debe averiguar en qué subdirectorio estaba), entonces ahora puede volver a crear el objeto perdido con objeto hash de nuevo.
para obtener una lista de todas las referencias con confirmaciones, árboles o blobs faltantes:
$ git for-each-ref --format='%(refname)' | while read ref; do git rev-list --objects $ref >/dev/null || echo "in $ref"; done
Puede que no sea posible eliminar algunas de esas referencias utilizando los comandos branch -d o tag -d regulares, ya que morirán si git nota la corrupción. Así que use el comando de plomería git update-ref -d $ ref en su lugar. Tenga en cuenta que en el caso de las ramas locales, este comando puede dejar una configuración obsoleta de la rama en .git / config. Se puede eliminar manualmente (busque la sección [branch "$ ref"]).
Después de que todas las referencias estén limpias, aún puede haber confirmaciones rotas en el reflog. Puede borrar todos los reflogs usando git reflog expire --expire = now --all. Si no desea perder todos sus reflogs, puede buscar los refs individuales para reflogs rotos:
$ (echo HEAD; git for-each-ref --format='%(refname)') | while read ref; do git rev-list -g --objects $ref >/dev/null || echo "in $ref"; done
(Tenga en cuenta la opción -g agregada a git rev-list.) Luego, use git reflog expire --expire = now $ ref en cada uno de esos. Cuando desaparezcan todos los refs y reflogs rotos, ejecute git fsck --full para verificar que el repositorio esté limpio. Los objetos colgantes están bien.
A continuación puede encontrar el uso avanzado de comandos que potencialmente pueden causar la pérdida de sus datos en su repositorio de git si no se usan con prudencia, así que haga una copia de seguridad antes de dañar accidentalmente su git. Pruébelo bajo su propio riesgo si sabe lo que está haciendo.
Para tirar de la rama actual en la parte superior de la rama aguas arriba después de buscar:
$ git pull --rebase
También puede intentar pagar la nueva rama y eliminar la anterior:
$ git checkout -b new_master origin/master
Para encontrar el objeto dañado en git para su eliminación, pruebe el siguiente comando:
while [ true ]; do f=`git fsck --full 2>&1|awk '{print $3}'|sed -r 's/(^..)(.*)/objects\/\1\/\2/'`; if [ ! -f "$f" ]; then break; fi; echo delete $f; rm -f "$f"; done
Para OSX, use en sed -Elugar de sed -r.
Otra idea es descomprimir todos los objetos de los archivos del paquete para regenerar todos los objetos dentro de .git / objects, así que intente ejecutar los siguientes comandos dentro de su repositorio:
$ cp -fr .git/objects/pack .git/objects/pack.bak
$ for i in .git/objects/pack.bak/*.pack; do git unpack-objects -r < $i; done
$ rm -frv .git/objects/pack.bak
Si lo anterior no ayuda, puede intentar rsync o copiar los objetos git de otro repositorio, por ejemplo
$ rsync -varu git_server:/path/to/git/.git local_git_repo/
$ rsync -varu /local/path/to/other-working/git/.git local_git_repo/
$ cp -frv ../other_repo/.git/objects .git/objects
Para arreglar la rama rota al intentar pagar de la siguiente manera:
$ git checkout -f master
fatal: unable to read tree 5ace24d474a9535ddd5e6a6c6a1ef480aecf2625
Intente eliminarlo y vuelva a realizar el pago desde el origen:
$ git branch -D master
$ git checkout -b master github/master
En caso de que git lo lleve a un estado separado, revise mastery combine en él la rama separada.
Otra idea es rebasar el maestro existente de forma recursiva:
$ git reset HEAD --hard
$ git rebase -s recursive -X theirs origin/master
Ver también:
.gitcarpeta, por supuesto) en el repositorio recién clonado ... y luego lo hicegit statusen el nuevo repositorio ... git detecta correctamente todos los cambios afectados en mis archivos y puedo comenzar mi trabajo nuevamente.