practices - git push tag
¿Cómo ver la fecha/marca de tiempo al margen al id. (2)
Usar la git stash list me muestra la lista de stashes con sus ID. Al usar git stash list --date=local o git stash list --date=relative me da su tiempo, pero no tengo idea de cuál es su ID correspondiente.
Quiero adquirir un alijo en un momento determinado.
Puede usar la sintaxis de stash@<date> directamente cuando se refiera a un stash:
$ git stash list --date=local
stash@{Sun Dec 21 22:32:14 2014}: WIP on develop: 7142a6e Update data files
stash@{Fri Dec 12 10:02:20 2014}: WIP on develop: c72abda Add initial calibration data
stash@{Wed Dec 10 10:02:05 2014}: WIP on master: 1d27422 Bug fix for gadgeteer
$ git show ''stash@{Fri Dec 12 10:02:20 2014}''
commit a096484501caf14942f01a6500a5d0c3476d3145
Merge: c72abda 861fff6
Author: Robert Xiao <[email protected]>
Date: Fri Dec 12 13:02:20 2014 -0500
WIP on develop: c72abda Add initial calibration data
...
$ git stash pop ''stash@{Fri Dec 12 10:02:20 2014}''
¡No hay necesidad de obtener la identificación del alijo en absoluto! Esto funciona incluso con date=relative siempre que las fechas relativas sean únicas.
git stash list simplemente ejecuta git log con un conjunto particular de opciones:
list_stash () {
have_stash || return 0
git log --format="%gd: %gs" -g --first-parent -m "$@" $ref_stash --
}
La parte $@ inserta las opciones adicionales que haya especificado (ninguna por defecto, pero --date=relative en este caso). 1
Cuando usas --date=relative esto modifica la salida de %gd : en lugar de un corto reflog con un índice , obtienes un corto reflog con una marca de tiempo relativa :
$ git stash list
stash@{0}: ...
$ git stash list --date=relative
stash@{4 minutes ago}: ...
La solución en este caso es usar su propio formato explícito, en lugar de dejar que --date=relative modifique cómo se muestra %gd . Por ejemplo:
$ git stash list --format=''%gd (%cr): %gs''
stash@{0} (4 minutes ago): ...
( %cr inserta la marca de tiempo de confirmación de la comisión, en un formato relativo; esto tiene sentido una vez que sepa que todo lo que hace el git stash es hacer un par de confirmaciones para usted, con las confirmaciones almacenadas en la referencia especial de stash lugar de en una rama) .
1 Al revisar esta respuesta, observo que los argumentos --first-parent y -m (literalmente presentes en el código de git stash ) parecen redundantes al principio, debido al argumento -g . El argumento -g para el git log le dice que mire solo el reflog, en lugar del historial de confirmación, en cuyo caso, - --first-parent no significa nada. Mientras tanto, -m le dice a git diff que divida una confirmación de fusión, pero estamos viendo los registros de confirmación, no las diferencias, así que, ¿qué está haciendo esto aquí?
La respuesta es que git log puede mostrar un parche, para el que ejecuta git diff , por lo que si presenta -p como argumento, el primer --first-parent -m limita esta diferencia para comparar la confirmación a la que apunta el reflog de stash. su primer padre. La confirmación de bolsa oculta a la que apunta el punto de entrada de reflog es la confirmación de árbol de trabajo, cuyo primer padre es la confirmación original en la que se cuelga la bolsa de ocultación. (Su segundo padre es el compromiso de índice y su tercer padre, si está presente, es el compromiso de todos los archivos o no rastreados). Así que estas opciones están ahí para hacer que git stash list -p difiera el commit del árbol de trabajo del stash contra el commit que era actual cuando se hizo el alijo en sí.
Esto es inteligente, pero bastante oscuro! :-)