packfiles.asc

Fichiers groupés

Revenons à la base de donnée d’objets de notre dépôt Git de test. Pour l’instant, elle contient 11 objets : 4 blobs, 3 arbres, 3 commits et 1 étiquette :

$ find .git/objects -type f
.git/objects/01/55eb4229851634a0f03eb265b69f5a2d56f341 # tree 2
.git/objects/1a/410efbd13591db07496601ebc7a059dd55cfe9 # commit 3
.git/objects/1f/7a7a472abf3dd9643fd615f6da379c4acb3e3a # test.txt v2
.git/objects/3c/4e9cd789d88d8d89c1073707c3585e41b0e614 # tree 3
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30 # test.txt v1
.git/objects/95/85191f37f7b0fb9444f35a9bf50de191beadc2 # tag
.git/objects/ca/c0cab538b970a37ea1e769cbbde608743bc96d # commit 2
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4 # 'test content'
.git/objects/d8/329fc1cc938780ffdd9f94e0d364e0ea74f579 # tree 1
.git/objects/fa/49b077972391ad58037050f2a75f74e3671e92 # new.txt
.git/objects/fd/f4fc3344e67ab068f836878b6c4951e3b15f3d # commit 1

Git compresse le contenu de ces fichiers avec zlib et on ne stocke pas grand chose ; au final, tous ces fichiers occupent seulement 925 octets. Ajoutons de plus gros contenu au dépôt pour montrer une fonctionnalité intéressante de Git. Pour la démonstration, nous allons ajouter le fichier repo.rb de la bibliothèque Grit. Il représente environ 22 ko de code source :

$ curl https://raw.githubusercontent.com/mojombo/grit/master/lib/grit/repo.rb > repo.rb
$ git checkout master
$ git add repo.rb
$ git commit -m 'added repo.rb'
[master 484a592] added repo.rb
 3 files changed, 709 insertions(+), 2 deletions(-)
 delete mode 100644 bak/test.txt
 create mode 100644 repo.rb
 rewrite test.txt (100%)

Si vous observez l’arbre qui en résulte, vous verrez l’empreinte SHA-1 du blob contenant le fichier repo.rb :

$ git cat-file -p master^{tree}
100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
100644 blob 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5      repo.rb
100644 blob e3f094f522629ae358806b17daf78246c27c007b      test.txt

Vous pouvez vérifier la taille de l’objet sur disque à l’aide de git cat-file :

$ git cat-file -s 033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5
22044

Maintenant, modifiez légèrement le fichier et voyez ce qui arrive :

$ echo '# testing' >> repo.rb
$ git commit -am 'modified repo.rb a bit'
[master 2431da6] modified repo.rb a bit
 1 file changed, 1 insertion(+)

Regardez l’arbre créé par ce commit et vous verrez quelque chose d’intéressant :

$ git cat-file -p master^{tree}
100644 blob fa49b077972391ad58037050f2a75f74e3671e92      new.txt
100644 blob b042a60ef7dff760008df33cee372b945b6e884e      repo.rb
100644 blob e3f094f522629ae358806b17daf78246c27c007b      test.txt

Ce blob est un blob différent. Bien que l’on ait ajouté une seule ligne à la fin d’un fichier en faisant 400, Git enregistre ce nouveau contenu dans un objet totalement différent :

$ git cat-file -s b042a60ef7dff760008df33cee372b945b6e884e
22054

Il y a donc deux objets de 22 ko quasiment identiques sur le disque. Ne serait-ce pas charmant si Git pouvait n’enregistrer qu’un objet en entier, le deuxième n’étant qu’un delta (une différence) avec le premier ?

Il se trouve que c’est possible. Le format initial dans lequel Git enregistre les objets sur le disque est appelé le format brut (loose object). De temps en temps, Git compacte plusieurs de ces objets en un seul fichier binaire appelé packfile (fichier groupé), afin d’économiser de l’espace et d’être plus efficace. Git effectue cette opération quand il y a trop d’objets au format brut, ou si l’on exécute manuellement la commande git gc, ou encore quand on pousse vers un serveur distant. Pour voir cela en action, vous pouvez demander manuellement à Git de compacter les objets en exécutant la commande git gc :

$ git gc
Counting objects: 18, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (18/18), done.
Total 18 (delta 3), reused 0 (delta 0)

Si l’on jette un œil dans le répertoire des objets, on constatera que la plupart des objets ne sont plus là et qu’un couple de fichiers est apparu :

$ find .git/objects -type f
.git/objects/bd/9dbf5aae1a3862dd1526723246b20206e5fc37
.git/objects/d6/70460b4b4aece5915caf5c68d12f560a9fe3e4
.git/objects/info/packs
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack

Les objets restant sont des blobs qui ne sont pointés par aucun commit. Dans notre cas, il s’agit des blobs « what is up, doc? » et « test content » créés plus tôt comme exemple. Puisqu’ils n’ont été ajoutés à aucun commit, ils sont considérés en suspend et ne sont pas compactés dans le nouveau fichier groupé.

Les autres fichiers sont le nouveau fichier groupé et un index. Le fichier groupé est un fichier unique rassemblant le contenu de tous les objets venant d’être supprimés du système de fichier. L’index est un fichier contenant les emplacements dans le fichier groupé, pour que l’on puisse accéder rapidement à un objet particulier. Ce qui est vraiment bien, c’est que les objets occupaient environ 15 ko d’espace disque avant gc et que le nouveau fichier groupé en occupe seulement 7. On a réduit l’occupation du disque de ½ en regroupant les objets.

Comment Git réalise-t-il cela ? Quand Git compacte des objets, il recherche les fichiers qui ont des noms et des tailles similaires, puis enregistre seulement les deltas entre une version du fichier et la suivante. On peut regarder à l’intérieur du fichier groupé et voir l’espace économisé par Git. La commande de plomberie git verify-pack vous permet de voir ce qui a été compacté :

$ git verify-pack -v .git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.idx
2431da676938450a4d72e260db3bf7b0f587bbc1 commit 223 155 12
69bcdaff5328278ab1c0812ce0e07fa7d26a96d7 commit 214 152 167
80d02664cb23ed55b226516648c7ad5d0a3deb90 commit 214 145 319
43168a18b7613d1281e5560855a83eb8fde3d687 commit 213 146 464
092917823486a802e94d727c820a9024e14a1fc2 commit 214 146 610
702470739ce72005e2edff522fde85d52a65df9b commit 165 118 756
d368d0ac0678cbe6cce505be58126d3526706e54 tag    130 122 874
fe879577cb8cffcdf25441725141e310dd7d239b tree   136 136 996
d8329fc1cc938780ffdd9f94e0d364e0ea74f579 tree   36 46 1132
deef2e1b793907545e50a2ea2ddb5ba6c58c4506 tree   136 136 1178
d982c7cb2c2a972ee391a85da481fc1f9127a01d tree   6 17 1314 1 \
  deef2e1b793907545e50a2ea2ddb5ba6c58c4506
3c4e9cd789d88d8d89c1073707c3585e41b0e614 tree   8 19 1331 1 \
  deef2e1b793907545e50a2ea2ddb5ba6c58c4506
0155eb4229851634a0f03eb265b69f5a2d56f341 tree   71 76 1350
83baae61804e65cc73a7201a7252750c76066a30 blob   10 19 1426
fa49b077972391ad58037050f2a75f74e3671e92 blob   9 18 1445
b042a60ef7dff760008df33cee372b945b6e884e blob   22054 5799 1463
033b4468fa6b2a9547a70d88d1bbe8bf3f9ed0d5 blob   9 20 7262 1 \
  b042a60ef7dff760008df33cee372b945b6e884e
1f7a7a472abf3dd9643fd615f6da379c4acb3e3a blob   10 19 7282
non delta: 15 objects
chain length = 1: 3 objects
.git/objects/pack/pack-978e03944f5c581011e6998cd0e9e30000905586.pack: ok

Ici, le blob 033b4, qui, si on se souvient bien, était la première version du fichier repo.rb, référence le blob b042a, qui est la seconde version du fichier. La troisième colonne de l’affichage est la taille de l’objet dans le fichier compact et on peut voir que b042a occupe 22 ko dans le fichier, mais que 033b4 occupe seulement 9 octets. Ce qui est aussi intéressant est que la seconde version du fichier est celle qui est enregistrée telle quelle, tandis que la version originale est enregistrée sous forme d’un delta. La raison en est que vous aurez sans doute besoin d’accéder rapidement aux versions les plus récentes du fichier.

Une chose intéressante à propos de ceci est que l’on peut recompacter à tout moment. Git recompacte votre base de donnée occasionnellement, en essayant d’économiser de la place. Vous pouvez aussi recompacter à la main, en exécutant la commande git gc vous-même.