2011-01-14 23 views
125

Durante il primo clone di un repository, git prima riceve gli oggetti (che è abbastanza ovvio), e quindi spende circa lo stesso tempo di "risoluzione dei delta". Cosa sta realmente accadendo durante questa fase del clone?Cosa sta effettivamente facendo git quando dice che "risolve delta"?

+0

Correlato: http://stackoverflow.com/questions/9478023/is-the-git-binary-diff-algorithm-delta-storage-standardized –

risposta

37

Git utilizza delta encoding per memorizzare alcuni oggetti nei file pack. Tuttavia, non è necessario riprodurre ogni singolo cambiamento su un dato file per ottenere la versione corrente, quindi Git ha anche istantanee occasionali del contenuto del file memorizzato. "Risoluzione dei delta" è il passo che si occupa di assicurarsi che tutto ciò sia coerente.

Here's a chapter dalla sezione "Git Internals" del libro Pro Git, disponibile online, che parla di questo.

+41

Questa risposta è errata. Sembra descrivere come funziona Mercurial, non Git. Sta arrivando nelle ricerche su Google per questo problema, quindi sento la necessità di rispondere. Git * non * memorizza le differenze tra i commit come delta; Git è un negozio "tutto l'oggetto". Pertanto, Git non ha bisogno di "istantanee" per mostrare un dato file perché la cronologia dei file non ha bisogno di essere ricostruita dai delta. È così che funziona Mercurial. –

+9

L'unico punto in cui la codifica delta entra in gioco è nel file pack che è strettamente per compressione e trasferimento - non altera il modo in cui Git "vede" il mondo. (http://kernel.org/pub/software/scm/git/docs/v1.6.2.3/technical/pack-heuristics.txt) Vedere sotto la risposta di araqnid per una risposta accurata. –

+2

Tutto "snapshot" significa in questo contesto è una copia completa di uno stato di file, piuttosto che una versione con codifica delta. Come hai detto, Git * non usa la codifica delta nei pacchetti. Nessuno ha detto che "altera il modo in cui Git vede il mondo"; per favore smetti di proiettare le tue ipotesi. – Amber

75

Le fasi di git clone sono:

  1. ricevere un file "pacchetto" di tutti gli oggetti nel database repo
  2. Creare un file indice per il pacchetto ricevuto
  3. Partenza la revisione testa (per un repository non semplice, ovviamente)

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

I file del pacchetto da non hanno gli ID oggetto effettivi al loro interno, solo il contenuto dell'oggetto. Quindi per determinare quali sono gli ID oggetto, git deve eseguire una decompressione + SHA1 di ogni oggetto nel pacchetto per produrre l'ID oggetto, che viene quindi scritto nel file indice.

Un oggetto in un file di pacchetto può essere memorizzato come un delta, ovvero una sequenza di modifiche da apportare ad un altro oggetto. In questo caso, git deve recuperare l'oggetto base, applicare i comandi e SHA1 il risultato. Potrebbe essere necessario derivare l'oggetto base stesso applicando una sequenza di comandi delta. (Anche se nel caso di un clone, l'oggetto di base sarà già stato rilevato, c'è un limite al numero di oggetti fabbricati memorizzati nella memoria).

In breve, la fase "risoluzione dei delta" implica la decompressione e il checksum dell'intero database dei pronti contro termine, che non sorprendentemente richiede molto tempo. Presumibilmente la decompressione e il calcolo degli SHA1 richiedono più tempo rispetto all'applicazione dei comandi delta.

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

+5

Può essere parallelizzato? – brooksbp

+0

Questa compressione delta è più che la memorizzazione di più oggetti in un flusso di dati zlib? – fuz

+0

@FUZxxl sì, sta usando un algoritmo come diff o xdelta per confrontare due blob e produrre uno script di modifica – araqnid

4

L'ambra sembra descrivere il modello di oggetto utilizzato da Mercurial o simili. Git non memorizza i delta tra le versioni successive di un oggetto, ma piuttosto le istantanee complete dell'oggetto, ogni volta. Quindi comprime queste istantanee utilizzando la compressione delta, cercando di trovare buoni delta da usare, indipendentemente da dove si trovano nella cronologia.

+5

In realtà, mentre Git è in grado di archiviare oggetti non necessariamente memorizzati come tali - come oggetti sfusi possono essere cancellati e sostituiti con contenuti impacchettati. Non credo che la risposta di Amber abbia detto nulla sulle versioni successive. – AlBlue

Problemi correlati