Deshacer git reset: difícil con archivos no confirmados en el área de ensayo

Estoy intentando recuperar mi trabajo. Estúpidamente lo hice git reset --hard, pero antes de eso solo get add .hice y no hice git commit. ¡Por favor ayuda! Aquí está mi registro:

MacBookPro:api user$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)

#   modified:   .gitignore
...


MacBookPro:api user$ git reset --hard
HEAD is now at ff546fa added new strucuture for api

¿Es posible deshacer git reset --harden esta situación?

Debería poder recuperar cualquier archivo que haya agregado al índice (por ejemplo, como en su situación, con git add .), aunque puede ser un poco complicado. Para agregar un archivo al índice, git lo agrega a la base de datos del objeto, lo que significa que se puede recuperar siempre que no se haya realizado la recolección de basura. Hay un ejemplo de cómo hacer esto en la respuesta de Jakub Narębski aquí:

• Recuperación del archivo agregado después de hacer git reset --hard HEAD ^

Sin embargo, probé eso en un repositorio de prueba y hubo un par de problemas, --cacheddebería ser --cache, y descubrí que en realidad no creaba el .git/lost-founddirectorio. Sin embargo, los siguientes pasos funcionaron para mí:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)")

Eso debería generar todos los objetos en la base de datos de objetos que no son accesibles por ninguna referencia, en el índice o mediante el reflog. La salida se verá así:

unreachable blob 907b308167f0880fb2a5c0e1614bb0c7620f9dc3
unreachable blob 72663d3adcf67548b9e0f0b2eeef62bce3d53e03

... y para cada una de esas manchas, puede hacer:

git show 907b308

Para generar el contenido del archivo.

¿Demasiada producción?

Actualización en respuesta al comentario de sehe a continuación:

Si encuentra que tiene muchas confirmaciones y árboles enumerados en la salida de ese comando, es posible que desee eliminar de la salida todos los objetos a los que se hace referencia de las confirmaciones no referenciadas. (Por lo general, puede volver a estas confirmaciones a través del reflog de todos modos; solo nos interesan los objetos que se han agregado al índice pero que nunca se pueden encontrar a través de una confirmación).

Primero, guarde la salida del comando, con:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)") > all

Ahora los nombres de objeto de esas confirmaciones inalcanzables se pueden encontrar con:

egrep commit all | cut -d ' ' -f 3

De modo que puede encontrar solo los árboles y objetos que se han agregado al índice, pero que no se han confirmado en ningún momento, con:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)") \
  $(egrep commit all | cut -d ' ' -f 3)

Eso reduce enormemente la cantidad de objetos que tendrá que considerar.

Actualización: Philip Oakley a continuación sugiere otra forma de reducir la cantidad de objetos a considerar, que es simplemente considerar los archivos modificados más recientemente .git/objects. Puede encontrar estos con:

find .git/objects/ -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort

(Encontré esa findinvocación aquí ). El final de esa lista podría verse así:

2011-08-22 11:43:43.0234896770 .git/objects/b2/1700b09c0bc0fc848f67dd751a9e4ea5b4133b
2011-09-13 07:36:37.5868133260 .git/objects/de/629830603289ef159268f443da79968360913a

En cuyo caso puede ver esos objetos con:

git show b21700b09c0bc0fc848f67dd751a9e4ea5b4133b
git show de629830603289ef159268f443da79968360913a

(Tenga en cuenta que debe eliminar el /al final de la ruta para obtener el nombre del objeto).

Acabo de hacer un git reset --hardcompromiso y perdí uno. Pero conocía el hash de confirmación, así que pude git cherry-pick COMMIT_HASHrestaurarlo.

Hice esto a los pocos minutos de perder el compromiso, por lo que puede funcionar para algunos de ustedes.

¡Gracias a Mark Longair recuperé mis cosas!

Primero guardé todos los hashes en un archivo:

git fsck --cache --unreachable $(git for-each-ref --format="%(objectname)") > allhashes

a continuación, los puse todos (eliminando el 'blob inalcanzable') en una lista y puse todos los datos en archivos nuevos ... tienes que elegir tus archivos y cambiarles el nombre de nuevo, lo que necesitas ... pero solo necesitaba unos pocos archivos ... espero que esto ayude a alguien ...

commits = ["c2520e04839c05505ef17f985a49ffd42809f",
    "41901be74651829d97f29934f190055ae4e93",
    "50f078c937f07b508a1a73d3566a822927a57",
    "51077d43a3ed6333c8a3616412c9b3b0fb6d4",
    "56e290dc0aaa20e64702357b340d397213cb",
    "5b731d988cfb24500842ec5df84d3e1950c87",
    "9c438e09cf759bf84e109a2f0c18520",
    ...
    ]

from subprocess import call
filename = "file"
i = 1
for c in commits:
    f = open(filename + str(i),"wb")
    call(["git", "show", c],stdout=f)
    i+=1

La solución de @ Ajedi32 en los comentarios funcionó para mí exactamente en esta situación.

git reset --hard @{1}

Tenga en cuenta que todas estas soluciones se basan en que no hay git gc, y algunas de ellas pueden causar una, por lo que comprimiría el contenido de su directorio .git antes de intentar algo para que tenga una instantánea a la que volver si no hay una. no funciona para ti.

Me encontré con el mismo problema, pero no había agregado los cambios al índice. Entonces, todos los comandos anteriores no me devolvieron los cambios deseados.

Después de todas las respuestas elaboradas anteriores, esta es una pista ingenua, pero puede ser que salve a alguien que no lo pensó primero, como lo hice yo.

Desesperado, intenté presionar CTRL-Z en mi editor (LightTable), una vez en cada pestaña abierta; afortunadamente, esto recuperó el archivo en esa pestaña, a su último estado antes del git reset --hard. HTH.

Esto probablemente sea obvio para los profesionales de git, pero quería publicarlo ya que en mi búsqueda frenética no vi que esto surgiera.

Puse en escena algunos archivos, e hice una git reset --hard, me asusté un poco, y luego noté que mi estado mostraba que todos mis archivos aún estaban organizados, así como todas sus eliminaciones sin configurar.

En este punto, puede confirmar esos cambios por etapas, siempre que no organice sus eliminaciones. Después de esto, solo tienes que reunir el coraje para hacerlo git reset --harduna vez más, lo que te devolverá a esos cambios que habías realizado y que ahora acabas de cometer.

Nuevamente, esto probablemente no sea nada nuevo para la mayoría, pero espero que, dado que me ayudó y no encontré nada que sugiriera esto, pueda ayudar a otra persona.

Dios mío, me tiré del pelo hasta que me encontré con esta pregunta y sus respuestas. Creo que la respuesta correcta y concisa a la pregunta formulada solo está disponible si reúne dos de los comentarios anteriores, así que aquí está todo en un solo lugar:

1. Como lo menciona chilicuil, ejecute git reflogpara identificar allí el hash de confirmación al que desea volver

2. Como lo mencionó akimsko, es probable que NO desee seleccionar con precisión a menos que solo haya perdido una confirmación, por lo que debe ejecutar git reset --hard <hash-commit-you-want>

Nota para los usuarios de egit Eclipse: no pude encontrar una manera de realizar estos pasos dentro de Eclipse con egit. Cerrar Eclipse, ejecutar los comandos anteriores desde una ventana de terminal y luego volver a abrir Eclipse funcionó bien para mí.

Las soluciones anteriores pueden funcionar, sin embargo, hay formas más simples de recuperarse de esto en lugar de pasar por el gitcomplejo deshacer. Supongo que la mayoría de los restablecimientos de git ocurren en una pequeña cantidad de archivos, y si ya usa VIM, esta podría ser la solución más eficiente en el tiempo. La advertencia es que ya debe estar usando ViM'spersistent-undo, que debería usar de cualquier manera, porque le brinda la capacidad de deshacer un número ilimitado de cambios.

Estos son los pasos:

1. En vim presione :y escriba el comando set undodir. Si ha persistent undoactivado en su .vimrc, mostrará un resultado similar a undodir=~/.vim_runtime/temp_dirs/undodir.

2. En su repositorio, use git logpara averiguar la última fecha / hora en que realizó la última confirmación

3. En su caparazón, navegue hasta su undodiruso cd ~/.vim_runtime/temp_dirs/undodir.

4. En este directorio, use este comando para encontrar todos los archivos que ha cambiado desde la última confirmación

   find . -newermt "2018-03-20 11:24:44" \! -newermt "2018-03-23" \( -type f -regextype posix-extended -regex '.*' \) \-not -path "*/env/*" -not -path "*/.git/*"

   Aquí "2018-03-20 11:24:44" es la fecha y hora de la última confirmación. Si la fecha en la que lo hizo git reset --hardes "2018-03-22", use "2018-03-22", luego use "2018-03-23". Esto se debe a una peculiaridad de la búsqueda, donde el límite inferior es inclusivo y el límite superior es exclusivo. https://unix.stackexchange.com/a/70404/242983

5. A continuación, vaya a cada uno de los archivos, ábralos en vim y haga un "20m anterior". Puede encontrar más detalles sobre "anterior" utilizando "h anterior". Aquí earlier 20msignifica volver al estado del archivo 20 minutos atrás, asumiendo que lo hizo git hard --reset, 20 minutos atrás. Repita esto con todos los archivos que se escupieron desde el findcomando. Estoy seguro de que alguien puede escribir un guión que combine estas cosas.

Estoy usando IntelliJ y pude simplemente revisar cada archivo y hacer:

Edit -> reload from disk

Afortunadamente, acababa de hacer lo git statuscorrecto antes de borrar mis cambios de trabajo, así que sabía exactamente lo que tenía que recargar.

Recordar la jerarquía de archivos y utilizar la técnica de Mark Longair con la modificación de Phil Oakley produce resultados espectaculares.

Básicamente, si al menos agregó los archivos al repositorio pero no los comprometió, puede restaurar utilizando interactivamente git show, inspeccionar el registro y usar la redirección de shell para crear cada archivo (recordando su ruta de interés).

HTH!

Si ha revisado recientemente un, git diffentonces hay otra forma de recuperarse de incidentes como este, incluso cuando aún no haya realizado los cambios: si el resultado de git difftodavía está en el búfer de la consola, puede desplazarse hacia arriba, copiar y pegar el diff en un archivo y utilizar la patchherramienta para aplicar el diff a su árbol: patch -p0 < file. Este enfoque me salvó algunas veces.