Cosa sta realmente facendo git quando dice che sta "risolvendo i delta"?

Durante il primo clone di un repository, git prima riceve gli oggetti (il che è abbastanza ovvio), quindi passa circa la stessa quantità di tempo a "risolvere i delta". Cosa sta realmente accadendo durante questa fase del clone?

Git utilizza la codifica delta per archiviare alcuni degli oggetti in pacchetti. Tuttavia, non si vuole avere a riprodurre ogni singola modifica mai su un dato file al fine di ottenere la versione attuale, in modo da Git ha anche istantanee occasionali del contenuto di file memorizzati pure. "Risolvere i delta" è il passo che consiste nel garantire che tutto ciò rimanga coerente.

Ecco un capitolo della sezione "Git Internals" del libro Pro Git, disponibile online, che ne parla.

Le fasi di git clonesono:

1. Ricevi un file "pack" di tutti gli oggetti nel database repo
2. Creare un file indice per il pacchetto ricevuto
3. Dai un'occhiata alla revisione principale (per un repo non nudo, ovviamente)

"Risoluzione dei delta" è il messaggio mostrato per la seconda fase, indicizzando il file del pacchetto ("git index-pack").

I file pack non contengono gli ID oggetto effettivi, ma solo il contenuto dell'oggetto. Quindi, per determinare quali sono gli ID oggetto, git deve fare una decompressione + SHA1 di ciascun oggetto nel pacchetto per produrre l'ID oggetto, che viene quindi scritto nel file indice.

Un oggetto in un file pack può essere archiviato come un delta, ovvero una sequenza di modifiche da apportare a qualche altro oggetto. In questo caso, git deve recuperare l'oggetto base, applicare i comandi e SHA1 il risultato. L'oggetto base stesso potrebbe dover essere derivato applicando una sequenza di comandi delta. (Anche se nel caso di un clone, l'oggetto base sarà già stato rilevato, esiste un limite al numero di oggetti fabbricati che sono memorizzati nella cache).

In sintesi, la fase "risoluzione dei delta" prevede la decompressione e il checksum dell'intero database di repository, che non sorprendentemente richiede molto tempo. Presumibilmente decomprimere e calcolare gli SHA1 richiede in realtà più tempo rispetto all'applicazione dei comandi delta.

Nel caso di un successivo recupero, il file del pacchetto ricevuto può contenere riferimenti (come basi di oggetti delta) ad altri oggetti che ci si aspetta già dal git di ricezione. In questo caso, git di ricezione riscrive effettivamente il file del pacchetto ricevuto per includere tali oggetti referenziati, in modo che qualsiasi file del pacchetto memorizzato sia autosufficiente. Questo potrebbe essere il punto di origine del messaggio "risoluzione dei delta".

L'ambra sembra descrivere il modello a oggetti che Mercurial o simili usano. Git non memorizza i delta tra le versioni successive di un oggetto, ma piuttosto istantanee complete dell'oggetto, ogni volta. Comprime quindi queste istantanee usando la compressione delta, cercando di trovare buoni delta da usare, indipendentemente da dove nella storia esistano.