Perché il commit di Git ha bisogno di due genitori?
Nella Guida agli hacker su Git , vedo questo modello mentale per le voci:
La guida mi dice che lo stash @ {0} ha bisogno sia di A che di B come genitori. Perché? Perché lo stash non punta semplicemente a B, eliminando la necessità di C? Penso che mi manchi qualcosa nella mia comprensione del Git.
Perché due cose sono nascoste: il contenuto indicizzato e il contenuto del worktree. Entrambi sono derivati dal commit estratto. Quando si apre lo stash, entrambi possono essere ripristinati.
Non sempre richiede due genitori, a volte in realtà ne richiede tre. ;)
Il seguente diagramma illustra lo scenario più semplice, con due genitori:
.----W
/ /
-----H----I
Quando si fa un git stash , Git crea due commit: il primo è un commit che applica le modifiche nascoste al commit HEAD corrente ( I ). Questo è il commit che registra i file nell'indice. L'indice prima della memorizzazione ha tutti i file nell'HEAD più quelli (aggiunti) a fasi, ecco perché commit I è figlio di H (commit puntato da HEAD ).
Il secondo ( W ) è figlio di quel commit e del commit puntato da HEAD. Questo è il commit stash, che viene utilizzato per applicare lo stash.
Ora, l'altro scenario si verifica quando fornisci l'opzione -u al comando stash . Questo dice a Git di mettere anche i file non tracciati. Lo schema ora diventa:
.----W----.
/ / /
-----H----I U
Il nuovo commit U ha tutte le modifiche introdotte dai file non tracciati. Si noti che non avrebbe senso che questo commit avesse genitori in quanto tali file non esistono nell'attuale HEAD .
Puoi vedere chiaramente quei diagrammi e le differenze eseguendo qualcosa come git log --graph stash@{0} o gitk stash@{0} .