cómo ver archivos sin seguimiento que eran “git stash -u”

5 minutos de lectura

avatar de usuario
Mathieu J.

Guardar contenido en git es muy útil. al esconder archivos sin rastrear y revisar su alijo de esta manera

echo test > foo
git stash -u # foo is stashed
git stash show -p stash@{0}

los archivos sin seguimiento no se muestran. como podemos verlos

Gracias

  • Posible duplicado de Git stash para parchear con archivos sin seguimiento

    – Mathieu J.

    16/09/2018 a las 19:15

avatar de usuario
Torek

Solo necesita mirar el tercer compromiso de alijo. Pero “solo necesito” subestima un poco las cosas, y esto no tiene sentido hasta que sepa lo que cometen los tres alijo están. Para ver lo que quiero decir, sigue leyendo.

Configuración: qué saber sobre los alijos

cuando corres git stash save o git stash pushla acción normal de Git es crear dos commits, ninguno de los cuales está en ninguna rama. Si dibuja la imagen “antes” de esta manera, tendría esta serie de confirmaciones:

...--o--o--*   <-- branch (HEAD)

Después git stash save completa, tienes dos nuevo confirmaciones que no están en la rama branch y tampoco en ninguna otra rama:

...--o--o--*   <-- branch (HEAD)
           |\
           i-w   <-- the stash

los w commit guarda el estado del árbol de trabajo mientras que el i commit guarda el índice. Cada uno de estos dos compromisos es muy parecido a cualquier otro compromiso y, de hecho, el i commit se hace usando la mayor parte de lo normal git commit mecanismo: Git escribe el índice actual en un árbol objeto usando git write-treeluego hace un cometer objeto usando git commit-tree. Si no sabes qué son estos objetos internos, no te preocupes demasiado por eso: el caso es que así también git commit hace la mayor parte de su trabajo, escribiendo un árbol y luego un objeto de confirmación. (El resto de git commit consiste en recopilar su mensaje de registro primero y actualizar el nombre de la sucursal al final).

los w commit es un poco más complicado porque tiene la formulario (pero no la intención) de un unir cometer, con dos padres en lugar de uno. Pero básicamente guarda una instantánea del árbol de trabajo, como si hubiera ejecutado git add en todos sus archivos rastreados.

cuando agregas --all o --include-untracked (-a o -u para abreviar), lo que git stash hace es que añade un tercera commit, que podemos dibujar de esta manera:

...--o--o--*   <-- branch (HEAD)
           |\
           i-w   <-- the stash
            /
           u

La tercera confirmación es una instantánea, pero es una instantánea muy extraña. Contiene solamente los archivos sin seguimiento, ya sea los archivos sin seguimiento pero no ignorados (git stash save -u), o los archivos sin seguimiento incluso los archivos no rastreados e ignorados (git stash save -a). tampoco tiene padre cometer.

Así que tenemos 3 confirmaciones en total para:
iíndice
wárbol de trabajo
usin seguimiento

La “pila” de alijo, los ID de hash de compromiso y los padres

Una razón1 que Git agregó el push verbo, como en git stash push—que por lo demás es básicamente un sinónimo de save—es que cuando creas un nuevo alijo, Git usa el alijo reflog para realizar un seguimiento de los escondites anteriores. El alijo actual es stash@{0} en términos de reflog, y el alijo anterior se convierte en stash@{1}.

Cada uno de estos nombres es solo un caso específico de una cosa más general que te da Git: puedes referirte a cualquier compromiso por cualquier nombre que se resuelva en el ID hash correcto. El “nombre verdadero” de cualquier compromiso es su ID de hash grande y feo. La documentación de gitrevisions tiene la descripción completa de todas las formas en que puede deletrear una ID de hash en Git; usando un nombre como branch o stash es una de esas maneras.

usando el nombre stash localiza cometer w específicamente. Git luego usa w sí mismo para encontrar cometer iy, si existe, cometer u. Git puede hacer esto porque cada compromiso incluye los ID de hash de sus padre se compromete que hace w tener la forma de una confirmación de fusión es que tiene al menos dos padres: ila confirmación del índice y *la confirmación en la que estaba sentado cuando ejecutó git stash save o git stash push en primer lugar.

Podemos modificar la mayoría de los especificadores de revisión (como stash) añadiendo un signo de intercalación ^ carácter y un número para mirar específicamente al padre numerado. Escribiendo stash^1 es una forma de nombrar commit *; escribiendo stash^2 es una forma de nombrar commit i. Si comete u existe, escribiendo stash^3 lo nombra. Tenga en cuenta que en algunos sistemas (Windows), ^ puede ser un carácter especial que requiere duplicación o comillas, por lo que en lugar de stash^3 puede que necesites stash^^3.


1La otra razón fue agregar la capacidad de ocultar parcialmente usando pathspecs: git stash save tomó cualquier argumento adicional como un mensaje para incluir en las confirmaciones ocultas, por lo que necesitaban un nuevo verbo que usara -m para especificar el mensaje, dejando espacio para argumentos pathspec.


Viendo el u cometer

podemos ver ninguna cometer usando git show. para alijo w comete esta falla porque Git piensa que el w commit es una fusión, por lo que podemos usar git stash show en lugar de. (Eso es una fusión, pero no una que git show puede mostrarse correctamente.) Mi respuesta anterior a una pregunta relacionada requiere usar git diff sobre el u commit, porque en ese caso particular, no queremos obtener el encabezado que git show muestra, pero si solo queremos ver la confirmación del archivo sin seguimiento, está bien usar git show aquí:

git show stash^3

por ejemplo. Aquí está la salida para el foo ejemplo anterior:

$ git show stash^3
commit 4c9bd2486706980f5a492d19c49270381db2d796
Author: Chris Torek <chris.torek gmail.com>
Date:   Sun Sep 16 12:35:03 2018 -0700

    untracked files on master: f72737e initial

diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo

Usando un nombre como stash@{1} identifica la confirmación en la entrada de reflog n.º 1, que es el siguiente alijo en su “pila de alijo”. (El reflog comienza a contar desde cero, por lo que stash y stash@{0} significan el mismo compromiso.) Así que para stash@{1} necesitarías stash@{1}^3 o quizás stash@{1}^^3.

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad