Abortar un pop de stash en Git

Mi caso de uso: acabo de intentar aparecer en la rama equivocada y tengo conflictos. Todo lo que necesito es deshacer el pop pero mantenerlo en la lista de alijo para que pueda pop en la rama correcta. Hice esto:

git reset HEAD --hard
git checkout my_correct_branch
git stash pop

Fácil.

Editar: De la documentación git help stash en la sección pop:

Aplicar el estado puede fallar con conflictos; en este caso, no se elimina de la lista de alijos. Necesitas resolver los conflictos a mano y llamar a git stash drop manualmente después.

Si se usa la opción index index, entonces intenta restablecer no solo los cambios del árbol de trabajo, sino también los del índice. Sin embargo, esto puede fallar, cuando tiene conflictos (que se almacenan en el índice, donde por lo tanto no puede ya aplicar los cambios como eran originalmente).

Intenta copiar todo tu repositorio en un nuevo dir (para que tengas una copia del mismo) y ejecuta:

git stash show y guarda esa salida en algún lugar si te importa.

Luego: git stash drop para soltar el alijo en conflicto entonces: git reset HEAD

Eso debería dejar su repositorio en el estado que estaba antes (con suerte, todavía no he sido capaz de reprogramar su problema)

===

Estoy tratando de repro su problema, pero todo lo que consigo cuando usin git stash pop es:

error: Your local changes to the following files would be overwritten by merge:
...
Please, commit your changes or stash them before you can merge.
Aborting

En un dir limpio:

git init
echo hello world > a
git add a & git commit -m "a"
echo hallo welt >> a
echo hello world > b
git add b & git commit -m "b"
echo hallo welt >> b
git stash
echo hola mundo >> a
git stash pop

No veo que git intente fusionar mis cambios, simplemente falla. ¿Tiene algún paso de repro que podamos seguir para ayudarlo?

Si no tienes que preocuparte por ningún otro cambio que hayas hecho y solo quieres volver a la última confirmación, entonces puedes hacer:

git reset .
git checkout .
git clean -f

OK, creo que he logrado encontrar un flujo de trabajo que te llevará de vuelta a donde necesitas estar (como si no hubieras hecho el pop).

TOME UNA COPIA DE SEGURIDAD DE ANTEMANO!! No se si esto funcionará para usted, así que copie todo su repositorio por si acaso no funciona.

1) Solucione los problemas de fusión y solucione todo el conflicto seleccionando todos los cambios que vienen del parche (en tortoisemerge, esto aparece como uno solo.REMOETE (de ellos)).

git mergetool

2) Confirmar estos cambios (que ya se añadirá mediante el comando mergetool). Dale un mensaje de confirmación de "fusionar" o algo que recuerdes.

git commit -m "merge"

3) Ahora todavía tendrá sus cambios locales no escalonados que comenzó originalmente, con una nueva confirmación del parche (podemos deshacernos de esto más adelante). Ahora confirma tus cambios no escalonados

git add .
git add -u .
git commit -m "local changes"

4) Invierta el parche. Esto se puede hacer con el siguiente comando:

git stash show -p | git apply -R

5) Confirme estos cambios:

git commit -a -m "reversed patch"

6) Deshágase del parche/desempaquete commits

git rebase -i HEAD^^^

De esto, elimine las dos líneas con 'merge' y 'reversed patch'.

7) Recupere sus cambios no cambiados y deshaga la confirmación de 'cambios locales'

git reset HEAD^

Lo he repasado con un ejemplo simple y te lleva de vuelta a donde quieres estar - directamente antes de que el alijo fuera popeado, con tus cambios locales y con el alijo todavía disponible para pop.

Resolví esto de una manera algo diferente. Esto es lo que pasó.

Primero, me metí en la rama equivocada y tuve conflictos. El alijo permaneció intacto, pero el índice estaba en resolución de conflictos, bloqueando muchos comandos.

Un simple git reset HEAD abortó la resolución de conflictos y dejó los cambios no comprometidos (y NO DESEADOS).

Varios git co <filename> revirtieron el índice al estado inicial. Finalmente, cambié la rama con git co <branch-name> y ejecuté una nueva git stash pop, que se resolvió sin conflicto.

Algunas ideas:

• Use git mergetool para dividir los archivos merge en partes originales y nuevas. Esperemos que uno de ellos es el archivo con sus cambios no-alijo en él.

• Aplica la diferencia del alijo al revés, para deshacer solo esos cambios. Probablemente tendrá que dividir manualmente los archivos con los conflictos de fusión (que con suerte el truco anterior funcionará).

No probé ninguno de estos, así que no estoy seguro de que funcionarán.

Usa git reflog para listar todos los cambios realizados en tu historial de git. Copie un id de acción y escriba git reset ACTION_ID

Podría reproducir clean git stash pop en el directorio "dirty", con cambios sin confirmar, pero aún no pop que genera un conflicto de fusión.

Si en el conflicto de fusión el alijo que intentó aplicar no desapareció, puede intentar examinar git show stash@{0} (opcionalmente con --ours o --theirs) y comparar con git statis y git diff HEAD. Debería ser capaz de ver qué cambios vinieron de la aplicación de un alijo.

Si DavidG está en lo cierto de que no hizo estallar el alijo debido al conflicto de fusión, entonces simplemente necesita limpiar su directorio de trabajo. Rápidamente git commit todo lo que te importa. (Puedes reset o squash la confirmación más tarde si no has terminado.) Luego con todo lo que te importa safe, git reset todo lo demás que git stash pop volcó en tu directorio de trabajo.

Si no hubo cambios escalonados antes de git stash pop, como en la pregunta, entonces los siguientes dos comandos deberían funcionar.

git diff --name-only --cached | xargs git checkout --ours HEAD
git ls-tree stash@{0}^3 --name-only | xargs rm

La primera invierte cualquier fusión del alijo, exitosa o no. El segundo elimina cualquier archivo no rastreado introducido por el alijo.

Desde man git stash : The working directory must match the index. Lo que @DavidG señala, el stash pop fallará si hay algún conflicto de archivos modificados no escalonados actualmente. Como tal, no deberíamos tener que preocuparnos por resolver conflictos de fusión más allá de volver a HEAD. Los archivos modificados restantes no están relacionados con el alijo, y se modificaron antes del stash pop

Si hubo cambios por etapas, no estoy claro si podemos confiar en los mismos comandos y es posible que desee probar la técnica de @Ben Jackson. Sugerencias apreciadas..

Aquí hay una configuración de prueba para todos los diversos casos https://gist.github.com/here/4f3af6dafdb4ca15e804

# Result:
# Merge succeeded in m (theirs)
# Conflict in b
# Unstaged in a
# Untracked in c and d

# Goal:
# Reverse changes to successful merge m
# Keep our version in merge conflict b
# Keep our unstaged a
# Keep our untracked d
# Delete stashed untracked c

Estoy publicando aquí con la esperanza de que otros mi encontrar mi respuesta útil. Tuve un problema similar cuando traté de hacer un stash pop en una rama diferente a la que había escondido desde. En mi caso, no tenía archivos que no estuvieran comprometidos o en el índice, pero aún así me metí en el caso de conflictos de fusión (el mismo caso que @pid). Como otros señalaron anteriormente, el pop de git stash fallido retuvo mi stash, luego un rápido git reset HEAD más volver a mi rama original y hacer el stash desde allí lo hizo resolver mi problema.