esconder show con descripción de post argumento ambiguo

Tengo esto en mi console windows-bash y repository git:

$ git stash list stash@{0}: WIP on Issue55A: cc3f7ff A3 stash@{1}: On Issue55A: A named stash 

Entonces me gustaría mostrar / aplicar / pop con el post (o parte de él) y estoy intentando este:

 $ git stash show stash^{/named} fatal: ambiguous argument 'stash^{/named}': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' 

He leído esta pregunta: ¿ stash @ {1} es ambiguo? Pero no tuvo suerte probar muchas opciones para escaping de las llaves.

De todos modos, con el post de error que recibo, creo que no hay problema con los caracteres de escape.

ACTUALIZADO: Sé que las opciones estándar de alijo pop / apply / show. Pero lo que pido es usarlos todos buscando por "descripción del post" o parte de él, como en esta respuesta: http://sofes.miximages.com/a/11688523/357618 Lo he probado solo con un guardado y Esto funciona, pero parece que cuando hay más de un escondite artículos en la list, esto no funciona.

Parece que debería funcionar (pero no funciona, y no se puede hacer funcionar fácilmente, explicaré por qué en un momento).

Como regla general, vale la pena intentar pasar el mismo argumento directamente a git rev-list para ver si eso puede resolverlo en un SHA-1. Si haces esto, recibirás el mismo post de error nuevamente, pero eso confirmará que no es algo que sucede en git stash , y que en su lugar es más genérico.

Aquí está la raíz del problema: los stash git abusa de los DAG de commit de git. (La palabra "abusos" puede ser un poco fuerte, pero creo que es justificable. 1 ) Lo que hace el stash es colgar dos (o a veces tres) confirmaciones de la sugerencia de bifurcación actual, pero no poner estas confirmaciones en ninguna twig. En cambio, si haces dos escondites en dos twigs diferentes, obtienes este tipo de arreglo (supongamos que stash@{1} se hizo en branch1 y stash@{0} en branch0 solo por consistencia y concreción):

 ... - A - B - C - D <-branch1 \ |\ \ iw <-- stash@{1} \ E - F <-- branch0 |\ iw <-- stash@{0} 

Estos pares iw son los commits ocultos. El i commit contiene el estado del índice y el w commit contiene el estado del tree de trabajo. Commit w es un commit de fusión, aunque no tiene nada que ver con la fusión; el primer padre de cada w es el commit en la twig ( D o F ) y el segundo es el i commit.

Tenga en count que solo hay una reference git involucrada aquí, que es refs/stash . La otra cosa que se dice que git stash es abusar (bastante less abuso en este caso, creo, ya que estamos en problemas a través del abuso commit-DAG) son los reflogs de git: escondites que no son los más recientes, stash o stash@{0} , simplemente son inputs de reflog: stash@{1} , stash@{2} , y así sucesivamente.

En cualquier caso, la revspec ^{/ text } ordera a git rev-parse que comience en el revspec dado y luego recorre el gráfico de compromiso hacia atrás, buscando un compromiso cuyo post contenga el text dado. En su caso, ambos depósitos se hicieron sin duda en la misma twig, algo así como:

 ... - A - B - C - D <-- branch |\__ | \ \ | iw <-- stash@{0} |\ iw <-- stash@{1} 

quizás, pero el punto es que a partir de cualquiera de estas confirmaciones de tree de trabajo, la caminata hacia atrás comprobará el compromiso D , luego confirmará C , luego B , luego A , y así sucesivamente. ¡Nunca golpeará al otro alijo en absoluto! Lo mismo ocurre incluso si las dos alforjas se cuelgan de dos compromisos diferentes:

 ... - A - B - C - D <-- branch |\ |\ iw iw 

Comenzando desde el alijo colgado de D , el recorrido de la list de reválvulas es (el segundo) w , luego D , C , B , A , y así sucesivamente. Comenzando por el que colgaba de B , es (el primero) w , luego B , luego A , y así sucesivamente.

De todos modos, la respuesta corta es que las búsquedas de text de compromiso se aplican al gráfico de compromiso, no a los reajustes, y las reservas de git se realizan mediante reflogs. Si git stash utilizara un método diferente para retener las confirmaciones y su parentesco, eso podría hacer que funcione, pero cambiar esto no sería trivial (en particular, tendría que admitir múltiples formularios ocultos durante algún período de transición).


1 Afirmo que tanto la palabra "abuso" como el abuso real en sí son justificables. La palabra parece justificada porque estos stash-bags no son realmente fusiones, simplemente se almacenan como fusiones para que el código de git stash pueda save dos o incluso tres treees de trabajo en una forma conveniente y recuperable. El abuso en sí parece justificado porque hace un trabajo perfecto de salvar los treees y hacerlos convenientes y recuperables.

Stash es como cualquier otra input de reflog, tiene un índice de {revisión}.

Lea aquí para get información sobre el reflog.

git stash pop

Elimine un solo estado escondido de la list oculta y aplíquelo sobre la estadística del tree de trabajo actual

git stash apply

Como pop, pero no elimine el estado de la list oculta

git stash show

Mostrar los cambios registrados en el alijo como una diferencia entre el estado escondido y su padre original


En su caso, necesitará usar el stash@{<revision>} para ejecutar cualquier acción oculta que desee realizar.

Por ejemplo:

 git stash show -p stash@{0}