Nouveautés de Git 2.50.0

Le projet Git a récemment publié la version 2.50.0 de Git.

Découvrons les points forts de cette nouvelle version, qui comprend les contributions de l'équipe Git de GitLab et de la communauté Git.

Nouvelle commande git-diff-pairs(1)

Les diffs sont au cœur de chaque revue de code et affichent toutes les modifications apportées entre deux révisions. Dans GitLab, ils apparaissent à plusieurs endroits, généralement dans l'onglet « Modifications » d'une merge request. En arrière-plan, la génération de diff est effectuée par git-diff(1).

Par exemple :

$ git diff HEAD~1 HEAD

Cette commande renvoie le diff complet de tous les fichiers modifiés. Son utilisation peut poser un problème de performance, car le nombre de fichiers modifiés entre différentes versions du code peut être très important, et le backend GitLab risque de dépasser le délai d'attente maximal qu'il s'impose pour exécuter cette commande. Pour les grands ensembles de modifications, il est préférable de pouvoir diviser le calcul des diffs en blocs plus petits et plus faciles à traiter.

Pour ce faire, vous pouvez utiliser git-diff-tree(1) pour récupérer des informations sur tous les fichiers modifiés :

$ git diff-tree -r -M --abbrev HEAD~ HEAD


:100644 100644 c9adfed339 99acf81487 M Documentation/RelNotes/2.50.0.adoc


:100755 100755 1047b8d11d 208e91a17f M GIT-VERSION-GEN

Git appelle ce résultat le format « brut ». En bref, chaque ligne de sortie répertorie les paires de fichiers et les métadonnées associées en lien avec les modifications apportées entre les révisions de début et de fin. En comparaison avec la génération de diffs pour les modifications importantes, ce processus est relativement rapide et fournit un résumé de tous les éléments qui ont été modifiés. Cette commande peut éventuellement effectuer une détection de changement de nom en ajoutant -M pour vérifier si les modifications identifiées étaient dues à un changement de nom de fichier.

Avec ces informations, nous pourrions utiliser git-diff(1) pour calculer chacun des diffs de paire de fichiers individuellement.

Par exemple, nous pouvons fournir directement des ID de blob :

$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f

Nous pouvons répéter ce processus pour chacune des paires de fichiers, mais lancer un processus Git distinct pour chaque diff de fichier n'est pas une approche efficace. De plus, lorsque vous utilisez des ID de blob, le diff perd certaines informations contextuelles telles que le statut de modification et les modes de fichier qui sont stockés dans l'objet arbre parent. En réalité, nous avons besoin d'un mécanisme pouvant recevoir des informations « brutes » sur les paires de fichiers et générant en sortie les diffs correspondants.

Avec la version 2.50.0, Git dispose d’une nouvelle commande intégrée git-diff-pairs(1), qui reçoit sur son entrée standard (« stdin ») les informations de paires de fichiers au format « brut » pour déterminer avec précision les diffs à générer.

L'exemple suivant montre comment cette commande peut être utilisée :

$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z

De cette façon, la sortie générée est identique à celle obtenue avec git-diff(1). En utilisant une commande distincte pour générer la sortie de diffs, la sortie « brute » de git-diff-tree(1) peut être divisée en lots plus petits de paires de fichiers et envoyée vers des processus git-diff-pairs(1) distincts. Cette approche résout le problème d'évolutivité mentionné précédemment, car le calcul des diffs ne s'effectue plus en une seule fois. Les futures versions de GitLab pourraient s'appuyer sur ce mécanisme pour améliorer les performances de génération de diff, en particulier lorsque de grands ensembles de modifications sont concernés.

Pour plus d'informations sur ce changement, consultez ce fil de discussion.

Ce projet a été mené par Justin Tobler.

Mises à jour des références par lots

Git fournit la commande git-update-ref(1) pour effectuer des mises à jour de références. Lorsqu'elle est associée à --stdin, il est possible de regrouper plusieurs mises à jour de références en une seule transaction en indiquant des instructions pour chaque mise à jour à effectuer sur l'entrée standard (« stdin »). La mise à jour des références en un seul lot offre également un comportement atomique : si une seule mise à jour échoue, la transaction est annulée et aucune référence n'est mise à jour.

Voici un exemple illustrant ce comportement :

# Create repository with three empty commits and branch named "foo"


$ git init


$ git commit --allow-empty -m 1


$ git commit --allow-empty -m 2


$ git commit --allow-empty -m 3


$ git branch foo


# Print out the commit IDs


$ git rev-list HEAD


cf469bdf5436ea1ded57670b5f5a0797f72f1afc


5a74cd330f04b96ce0666af89682d4d7580c354c


5a6b339a8ebffde8c0590553045403dbda831518


# Attempt to create a new reference and update existing reference in transaction.


# Update is expected to fail because the specified old object ID doesn’t match.


$ git update-ref --stdin <<EOF


> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc


> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c


> EOF


fatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c


# The "bar" reference was not created.


$ git switch bar


fatal: invalid reference: bar

En comparaison avec la mise à jour de nombreuses références une par une, la mise à jour par lot est également beaucoup plus efficace. Toutefois, dans certaines circonstances, il peut être acceptable qu'un sous-ensemble des mises à jour de références demandées échoue. Mais nous voulons quand même bénéficier de l'efficacité des mises à jour par lot.

Avec cette version, git-update-ref(1) met à disposition la nouvelle option --batch-updates, qui permet aux mises à jour de se poursuivre même lorsqu'une ou plusieurs mises à jour de références échouent.

Dans ce mode, les échecs individuels sont signalés dans le format suivant :

rejected SP (<old-oid> | <old-target>) SP (<new-oid> | <new-target>) SP <rejection-reason> LF

Il est ainsi possible de poursuivre les mises à jour de références réussies, tout en fournissant un contexte indiquant celles qui ont été rejetées et pour quelle raison.

Voici ce que nous obtenons en utilisant le même exemple de dépôt que dans l'exemple précédent :

# Attempt to create a new reference and update existing reference in transaction.


$ git update-ref --stdin --batch-updates <<EOF


> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc


> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c


> EOF


rejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided


# The "bar" reference was created even though the update to "foo" was rejected.


$ git switch bar


Switched to branch 'bar'

Cette fois, avec l'option --batch-updates, la création de la référence a réussi même si la mise à jour n'a pas fonctionné. Cette série de diffs est un aperçu des futures améliorations des performances de git-fetch(1) et git-receive-pack(1) lors de la mise à jour de références par lot.

Pour plus d'informations, consultez ce fil de discussion.

Ce projet a été mené par Karthik Nayak.

Nouvelle option de filtre pour git-cat-file(1)

Avec git-cat-file(1), il est possible d’afficher des informations pour tous les objets contenus dans le dépôt via l'option --batch–all-objects.

En voici un exemple :

# Setup simple repository.


$ git init


$ echo foo >foo


$ git add foo


$ git commit -m init


# Create an unreachable object.


$ git commit --amend --no-edit


# Use git-cat-file(1) to print info about all objects including unreachable objects.


$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'


commit 0b07e71d14897f218f23d9a6e39605b466454ece


tree 205f6b799e7d5c2524468ca006a0131aa57ecce7


blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99


commit c999f781fd7214b3caab82f560ffd079ddad0115

Dans certains cas, un utilisateur peut effectuer une recherche dans tous les objets du dépôt, mais n'afficher qu'un sous-ensemble basé sur un attribut spécifique.

Par exemple, si nous voulons voir uniquement les objets qui sont des commits, nous pouvons utiliser grep(1) :

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit


commit 0b07e71d14897f218f23d9a6e39605b466454ece


commit c999f781fd7214b3caab82f560ffd079ddad0115

Bien que cela fonctionne, un des inconvénients du filtrage de la sortie est que git-cat-file(1) doit toujours parcourir tous les objets du dépôt, même ceux qui n'intéressent pas l'utilisateur. Cette approche peut se révéler assez inefficace.

Avec la version 2.50.0, git-cat-file(1) dispose désormais de l'option --filter, qui n'affiche que les objets correspondant aux critères spécifiés. Celle-ci est similaire à l'option du même nom pour git-rev-list(1), mais seul un sous-ensemble des filtres est pris en charge : blob:none, blob:limit=, ainsi que object:type=.

Comme dans l'exemple précédent, il est possible de filtrer les objets par type avec Git directement :

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'


commit 0b07e71d14897f218f23d9a6e39605b466454ece


commit c999f781fd7214b3caab82f560ffd079ddad0115

Non seulement il est pratique de laisser Git s'occuper du traitement, mais pour les dépôts volumineux contenant de nombreux objets, c'est aussi potentiellement plus efficace. Si un dépôt dispose d'index bitmap, Git peut rechercher efficacement des objets d'un type spécifique, sans scanner le fichier d'empaquetage (« packfile »), ce qui accélère significativement le processus.

Les benchmarks effectués sur le dépôt Chromium montrent des améliorations significatives :

Benchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter


Time (mean ± σ): 82.806 s ± 6.363 s [User: 30.956 s, System: 8.264 s]


Range (min … max): 73.936 s … 89.690 s 10 runs


Benchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag


Time (mean ± σ): 20.8 ms ± 1.3 ms [User: 6.1 ms, System: 14.5 ms]


Range (min … max): 18.2 ms … 23.6 ms 127 runs


Benchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit


Time (mean ± σ): 1.551 s ± 0.008 s [User: 1.401 s, System: 0.147 s]


Range (min … max): 1.541 s … 1.566 s 10 runs


Benchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree


Time (mean ± σ): 11.169 s ± 0.046 s [User: 10.076 s, System: 1.063 s]


Range (min … max): 11.114 s … 11.245 s 10 runs


Benchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob


Time (mean ± σ): 67.342 s ± 3.368 s [User: 20.318 s, System: 7.787 s]


Range (min … max): 62.836 s … 73.618 s 10 runs


Benchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none


Time (mean ± σ): 13.032 s ± 0.072 s [User: 11.638 s, System: 1.368 s]


Range (min … max): 12.960 s … 13.199 s 10 runs


Summary


git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag


74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit


538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree


627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none


3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob


3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter

Il est intéressant de noter que ces résultats indiquent que le temps de calcul est maintenant proportionnel au nombre d'objets pour un type donné plutôt qu'au nombre total d'objets dans le fichier d'empaquetage. Pour plus d'informations, consultez ce fil de discussion.

Ce projet a été mené par Patrick Steinhardt.

Amélioration des performances lors de la génération d'archives

Avec Git, vous pouvez générer une archive d'un dépôt qui contient un ensemble spécifié de références et d'objets accessibles qui les accompagnent via la commande git-bundle(1). Cette opération est utilisée par GitLab pour générer des sauvegardes de dépôt et dans le cadre du mécanisme bundle-URI.

Pour les grands dépôts contenant des millions de références, cette opération peut prendre plusieurs heures, voire même plusieurs jours. Par exemple, avec le dépôt principal de GitLab (gitlab-org/gitlab), les temps de sauvegarde étaient d'environ 48 heures. Des recherches ont révélé la présence d'un goulot d'étranglement des performances en raison de la façon dont Git effectuait une vérification pour éviter que des références dupliquées ne soient incluses dans l'archive. L'implémentation utilisait une boucle for imbriquée pour itérer et comparer toutes les références répertoriées, ce qui entrainait une complexité temporelle O(N^2). Cette façon de procéder dégradait fortement les performances à mesure que le nombre de références dans un dépôt augmentait.

Dans la version 2.50.0, ce problème a été résolu en remplaçant les boucles imbriquées par un tableau associatif, ce qui a permis d'accélérer considérablement le processus. Le benchmark suivant montre l'amélioration des performances lors de la création d'une archive avec un dépôt contenant 100 000 références :

Benchmark 1: bundle (refcount = 100000, revision = master)


Time (mean ± σ): 14.653 s ± 0.203 s [User: 13.940 s, System: 0.762 s]


Range (min … max): 14.237 s … 14.920 s 10 runs


Benchmark 2: bundle (refcount = 100000, revision = HEAD)


Time (mean ± σ): 2.394 s ± 0.023 s [User: 1.684 s, System: 0.798 s]


Range (min … max): 2.364 s … 2.425 s 10 runs


Summary


bundle (refcount = 100000, revision = HEAD) ran


6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

Pour en savoir plus, découvrez notre article de blog qui explique comment nous avons réduit les temps de sauvegarde du dépôt GitLab de 48 heures à 41 minutes et consultez ce fil de discussion.

Ce projet a été mené par Karthik Nayak.

Meilleur dégroupage des URI d'archives

À l'aide du mécanisme bundle-uri dans Git, il est possible de fournir aux clients les emplacements pour récupérer des archives dans le but d'accélérer les clones et les récupérations. Lorsqu'un client télécharge une archive, les références sous refs/heads/* et les objets qui les accompagnent sont copiés de l'archive dans le dépôt. Une archive peut contenir des références supplémentaires en dehors de refs/heads/* telles que refs/tags/*, qui sont simplement ignorées lors de l'utilisation de bundle-uri sur le clone.

Dans Git 2.50.0, cette restriction est levée. Par conséquent, toutes les références correspondant à refs/* contenues dans l'archive téléchargée sont copiées.

Scott Chacon, qui a contribué à cette fonctionnalité, montre la différence lors du clonage de gitlab-org/gitlab-foss :

$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49


Cloning into 'gl2.49'...


remote: Enumerating objects: 1092703, done.


remote: Counting objects: 100% (973405/973405), done.


remote: Compressing objects: 100% (385827/385827), done.


remote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)


Receiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.


Resolving deltas: 100% (710976/710976), completed with 9081 local objects.


Checking objects: 100% (4194304/4194304), done.


Checking connectivity: 959668, done.


Updating files: 100% (59972/59972), done.


$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50


Cloning into 'gl-2.50'...


remote: Enumerating objects: 65538, done.


remote: Counting objects: 100% (56054/56054), done.


remote: Compressing objects: 100% (28950/28950), done.


remote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)


Receiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.


Resolving deltas: 100% (27401/27401), completed with 8564 local objects.


Updating files: 100% (59972/59972), done.

En comparant ces résultats, nous constatons que Git 2.50.0 récupère 43 887 objets (40,42 MiB) après l'extraction de l'archive, tandis que Git 2.49.0 récupère un total de 959 773 objets (366,94 MiB). Git 2.50.0 récupère environ 95 % d'objets en moins et 90 % de données en moins, ce qui est avantageux aussi bien pour le client que le serveur. Le serveur doit traiter beaucoup moins de données à destination du client, et ce dernier doit télécharger et extraire moins de données. Dans l'exemple fourni par Scott, cela a conduit à une accélération de 25 %.

Pour en savoir plus, consultez ce fil de discussion.

Cette série de contributions a été fournie par Scott Chacon.

En savoir plus

Cet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git pour cette nouvelle version. Vous pouvez approfondir ce sujet en lisant l'annonce officielle du projet Git et en consultant ces ressources.