Que fait réellement git quand il dit qu'il «résout les deltas»?

Lors du premier clone d'un référentiel, git reçoit d'abord les objets (ce qui est assez évident), puis passe à peu près le même temps à "résoudre les deltas". Que se passe-t-il réellement pendant cette phase du clone?

Git utilise le codage delta pour stocker certains des objets dans des fichiers pack. Cependant, vous ne voulez pas avoir à lire chaque changement unique jamais sur un fichier donné afin d'obtenir la version actuelle, alors Git a aussi des instantanés occasionnels du contenu des fichiers stockés ainsi. «Résoudre les deltas» est l'étape qui consiste à s'assurer que tout cela reste cohérent.

Voici un chapitre de la section "Git Internals" du livre Pro Git, disponible en ligne, qui en parle.

Les étapes de git clonesont:

1. Recevoir un fichier "pack" de tous les objets de la base de données du référentiel
2. Créer un fichier d'index pour le pack reçu
3. Vérifiez la révision principale (pour un repo non nu, évidemment)

"Resolving deltas" est le message affiché pour la deuxième étape, indexant le fichier pack ("git index-pack").

Les fichiers de pack ne contiennent pas les ID d'objet réels, mais uniquement le contenu de l'objet. Donc, pour déterminer quels sont les ID d'objet, git doit faire une décompression + SHA1 de chaque objet du pack pour produire l'ID d'objet, qui est ensuite écrit dans le fichier d'index.

Un objet dans un fichier pack peut être stocké en tant que delta, c'est-à-dire une séquence de modifications à apporter à un autre objet. Dans ce cas, git doit récupérer l'objet de base, appliquer les commandes et SHA1 le résultat. L'objet de base lui-même peut devoir être dérivé en appliquant une séquence de commandes delta. (Même si dans le cas d'un clone, l'objet de base aura déjà été rencontré, il y a une limite au nombre d'objets fabriqués mis en cache en mémoire).

En résumé, l'étape de «résolution des deltas» implique la décompression et la somme de contrôle de l'ensemble de la base de données de repo, ce qui, sans surprise, prend un temps assez long. La décompression et le calcul des SHA1 prennent vraisemblablement plus de temps que l'application des commandes delta.

Dans le cas d'une extraction ultérieure, le fichier pack reçu peut contenir des références (en tant que bases d'objets delta) à d'autres objets que le git récepteur est censé avoir déjà. Dans ce cas, le git récepteur réécrit en fait le fichier de pack reçu pour inclure de tels objets référencés, de sorte que tout fichier de pack stocké soit autonome. C'est peut-être là que provient le message «résolution des deltas».

Amber semble décrire le modèle d'objet utilisé par Mercurial ou similaire. Git ne stocke pas les deltas entre les versions suivantes d'un objet, mais plutôt des instantanés complets de l'objet, à chaque fois. Il compresse ensuite ces instantanés à l'aide de la compression delta, en essayant de trouver les bons deltas à utiliser, quel que soit leur emplacement dans l'historique.