¿Por qué el compromiso de escondite de Git necesita dos padres?
En la Hacker's Guide to Git , veo este modelo mental para los escondites:
La guía me dice que stash @ {0} necesita tanto A como B como padres. ¿Por qué? ¿Por qué el alijo no solo apunta a B, eliminando la necesidad de C? Creo que me falta algo en mi comprensión de Git.
Respuestas:
Porque hay dos cosas escondidas: el contenido indexado y el contenido del árbol de trabajo. Ambos se derivan del commit desprotegido. Al abrir el alijo, ambos se pueden restaurar.
git add.
No siempre requiere dos padres, a veces en realidad requiere tres.
El siguiente diagrama ilustra el escenario más simple, con dos padres:
.----S
/ /
-----H----I
Aquí Hrepresenta su cabeza actual, que es la rama maestra en su ejemplo, y se crean dos confirmaciones secundarias cuando ejecuta git-stash.
El primero es I, que representa el índice en el momento del almacenamiento. En otras palabras, esta confirmación contiene los cambios que se organizaron antes de la ocultación. Tiene un padre único, que es el commit al que HEAD señaló. El segundo ( S) es el commit de ocultación, que contiene archivos que se modificaron antes de la ocultación. Tiene dos confirmaciones porque sus cambios podrían estar por encima de los de I y de H, es decir, podrían afectar a los archivos que se organizaron o no.
El otro escenario ocurre cuando proporciona el -ucambio al stashcomando, que le dice a Git que también guarde los archivos no rastreados. El diagrama ahora se convierte en:
.----S----.
/ / /
-----H----I U
El nuevo Ucommit tiene todos los cambios introducidos por los archivos no rastreados. Tenga en cuenta que no tendría sentido que este compromiso tenga padres, ya que esos archivos no existen en la actualidad HEAD. El alijo comprometerse Sahora tiene tres padres: H, Iy Uahora cuando se aplica el alijo cometer Git también se aplicará a los cambios sin seguimiento.
Puede ver esos diagramas y las diferencias claramente ejecutando algo como git log --graph stash@{0}o gitk stash@{0}.