Git riutilizzerà lo stesso blob.
Ho fatto un test. Ho fatto 3 commit. Per prima cosa, eseguo il commit di un file binario, quindi ho modificato il file binario e l'ho eseguito nuovamente. Poi alla fine ho sovrascritto il file con il binario originale usato nel primo commit e ho eseguito il commit di nuovo.
Il contenuto di file binari nel 1 ° & 3 commit è lo stesso. Ogni commit è il HEAD dei seguenti rami:
1st commit: "FIRST". 2 ° commit: "SECONDO". 3 commit: "master"
Quindi se si esegue "git cat-file -p FIRST^{tree}", mostra il codice hash del file binario.
$ git cat-file -p FIRST^{tree}
100644 blob ec049240a47b472bd7c31d1fa27118c4fe2f1229 test.db3
$ git cat-file -p SECOND^{tree}
100644 blob a47bb3727e5aefe3ec386bec5520f3e4ffb3a4c5 test.db3
$ git cat-file -p master^{tree}
100644 blob ec049240a47b472bd7c31d1fa27118c4fe2f1229 test.db3
Troverete che il codice hash del blob di 1a e 3a commit sono gli stessi.
git è così intelligente da controllare se esiste un blob per un codice hash e riutilizzare quel blob se trovato.
fonte
2014-09-17 07:54:08
Questa è la risposta corretta. La chiave qui è che SHA1 è, beh, la "chiave" del file, in termini di un database di chiavi/valori, cioè. SHA1 è un checksum crittografico del contenuto del file (oltre ad alcune cose e informazioni sulle dimensioni esclusive). Due file identici calcolano lo stesso checksum e quindi memorizzano un singolo oggetto git, il cui nome è il checksum SHA-1. Non importa quando viene calcolato il checksum, solo se un file che ha quel checksum come nome è nel repository. – torek
TIL: git cat-file;) – awendt
@torek: esattamente. Internamente, un repository git è più o meno un database di valori-chiave. Le chiavi sono i checksum SHA1 degli oggetti git (commit, alberi, blob e tag) e il valore è l'oggetto corrispondente. Il riutilizzo di BLOB (e alberi) è una conseguenza automatica di questa struttura. – sleske