puesta en escena, pero no comprometidos, archivos borrados después de emitir: git reset CABEZA --hard

Question

Normalmente, se puede hacer:

$ echo "Stanley, you must beware of the Drive bee" > file-a 
$ echo "What's a Drive bee?" > file-b 
$ git init . 
$ git add file-b 
$ git commit file-b -m "We don't know, but whatever error you make with it could be fatal." 
$ git reset --hard HEAD 
$ ls 
file-a file-b 

Creo que hice algo muy malo:

$ echo "What are you doing, you darn ?" > file-a 
$ echo "Can't you see I'm trying to drive?" > file- 
$ git init . 
$ git add -A 
$ git commit file- -m "Oh, my God! [It's] the Drive !" 
$ git reset --hard HEAD 
$ ls 
file- 

Resultado: todo por etapas, pero no comprometidos, los archivos borrados 0_o

git reset --hard HEAD\^ 
fatal: ambiguous argument 'HEAD^': unknown revision or path not in the working tree. 

¿hay algo que pueda hacer para recuperar el archivo que acaba de eliminar? En otras palabras, ¿es posible restaurar un repositorio de git a la condición que tenía antes (o cuando) se emitió el comando git add -A?

Answer 1

Sí, en realidad tienes mucha suerte. Lo que agregaste al índice de Git está ahí, de alguna manera. De hecho, Git crea objetos blob para cada archivo cuando se agrega al índice. El índice en sí solo almacena los objetos del árbol.

Así que sí, se crearon objetos blob para los archivos montados. Todo lo que pierde es la información del árbol, es decir, la ruta y el nombre del archivo, pero puede recuperar el contenido.

intente ejecutar git fsck y usted debe obtener una lista de las gotas que cuelgan:

Checking object directories: 100% (256/256), done. 
dangling blob ac28af8d84fc71eb247ccf665c6d0f4bf1822520 
dangling blob 2d152ff9f09cb08ebc495f453da63eddaa9e249f 
dangling blob cd9567427762cd8066b4e802e5c170a31a026100 

entonces usted puede recuperar el contenido haciendo git cat-file -p ac28af8d. Por ejemplo, puede canalizarlo a un archivo:

git cat-file -p ac28af8d > recovered-file 

Haga eso para todos ellos y los tiene de vuelta.

Answer 2

La siguiente secuencia de comandos de restaurar todas las gotas que cuelgan de git fsck salida en archivos:

i=0; for x in `git fsck | grep "dangling blob [0-9a-f]" | cut -d ' ' -f 3`; do git cat-file -p $x > /tmp/test${i}; i=$((i+1)) ; done 

Como se puede ver, la salida de cada archivo original se restaura en genérico nombre de fichero/tmp/test $ {i} .. . no he encontrado una manera de restaurar el nombre del archivo sin embargo ... el comando que he probado es git ls-tree:

primera vez que lo tomó posibles objetos:

./.git/objects/37 
./.git/objects/37/5187f5882593f7e52c8efef602d98f1f049c5d 
./.git/objects/37/98be05fcbd7c79e08703aead800529b362332b 

Luego, traté de hacer el truco ls-tree, pero no identificó esto como un objeto válido.

/<myproj>/.git/objects/37 ]$ git ls-tree 5187f5882593f7e52c8efef602d98f1f049c5d 
fatal: Not a valid object name 5187f5882593f7e52c8efef602d98f1f049c5d 

Answer 3

me gusta mucho la siguiente solución de este answer a una cuestión conexa de desbordamiento de pila:

1. Uso git log --diff-filter=D --summary para obtener todas las confirmaciones que se han eliminado los archivos y los archivos borrados
2. Uso git checkout $commit~1 filename a restaurar el archivo eliminado

Es conciso e intuitivo.