2009-10-09 15 views
9

Mi repositorio git de trabajo se rompe, se pierde la pista de todos los archivos en el mismo, es decir,Recuperación rota repositorio git

 
$ git log 
fatal: bad default revision 'HEAD' 
 
$ git status 
... told me that all the files are new 

Sin embargo el directorio .git contiene mis objetos.

 
$ du -sh .git 
34M .git 
 
$ git count-objects 
4151 objects, 32692 kilobytes 
 
$ git --version 
git version 1.6.0.4 

La última cosa que recuerdo haber hecho antes de que se estaba creando mal salió (--mirror clon) un repositorio de copia de seguridad en un servidor montado en NFS. Sin embargo, el repositorio de copia de seguridad clonado se rompe de la misma manera.

¿Cómo puedo restaurar mi repositorio?

+0

¿Hay una rama 'master' en su repositorio? Además, ¿obtiene un resultado diferente con 'git log --all'? –

+0

No, 'git branch -a' no me dice nada. – Eyoka

Respuesta

8

Debe haber algo más que el clon, pero sé lo difícil que es recordar esas cosas.

Lo primero que debes hacer es buscar en .git/refs y ver si hay algo válido allí (no soy demasiado optimista ya que dices que no parece haber ninguna rama, pero vale la pena) un disparo). Si existen referencias válidas, es posible que pueda obtener información del git-reflog.

A continuación, comenzaría a echar un vistazo a git-fsck. Su objetivo principal es verificar la conectividad y la validez de los objetos en la base de datos. Dependiendo de qué sucedió exactamente con su repositorio, puede necesitar --unreachable o --lost-found. Esperemos que los objetos estén intactos, de modo que todo lo que necesita hacer es encontrar algunos hashes de confirmación colgantes para verificar y recrear ramas en.

+0

Gracias. He arreglado el repositorio de forma manual. Resultó que faltaban las ramas (archivos en .git/refs/heads), pero los objetos estaban intactos. Pude obtener hashes de confirmación de la punta de cada rama de .git/logs/HEAD, y los usé para recrear los archivos de ramas. No sabía el comando git-fsck entonces. Sin embargo, todavía tengo curiosidad de cómo sucedió esto, obviamente no hice

git branch -d
. No conozco muchos comandos de git, los únicos que recuerdo haber sido
git reset
y
git remote rm ...
Eyoka

1

Puede examinar de forma manual, pero eso requeriría cierto conocimiento sobre el formato del repositorio.

Sin mirar el repositorio es difícil saber qué está sucediendo, pero probablemente algún archivo fue dañado.

Ejecute git fsck y le indicará si su repositorio sigue siendo válido.

Publique el resultado de la ejecución de git fsck y eso debería ayudarnos a ayudarlo.

1

Intente comprobar si cada uno de sus archivos en .git/son propiedad del usuario actual.

Tuve el mismo problema al darme cuenta de que había realizado algunas confirmaciones con el usuario raíz y que los objetos creados (en .git/objects) pertenecían al root, produciendo errores al ejecutar git como usuario habitual.

Este comando resuelto el problema:

sudo chown jb:jb .git/ -R * 
1

Tengo este problema apenas ahora después de mi solicitud GitHub (PC) estrellado. Mi sucursal desapareció cuando usé git branch y me siguió pidiendo que hiciera mi confirmación inicial. Lo solucioné localizando mi sucursal en .git/refs/heads/ y renombrándola de mybranch.lock a solo mybranch (quite el candado).

+0

Esta respuesta me ayudó en mi caso. Estaba usando GitHub para Windows y de repente traté todos los archivos en el repositorio como un archivo nuevo. git log returned "fatal: mala revisión por defecto 'HEAD'". git fsck devolvió un montón de commits pendientes. Solo tuve que cambiar el nombre del archivo master.lock al master –

0

Tuve este problema después de que un desarrollador hizo un $ git init dentro del maestro desnudo de un repositorio centralizado.

Si está trabajando con un repositorio sin directorio de trabajo, busque una carpeta .git; borrar esto debería rectificar el problema.