Blog Open source Nouveautés de Git 2.48.0
Mise à jour : January 20, 2025
Lecture : 9 min

Nouveautés de Git 2.48.0

Découvrez la dernière version de Git, y compris un nouveau système de compilation ainsi que des optimisations dans le nouveau backend « reftable ».

git 2 - cover

Le projet Git a récemment publié la version 2.48.0 de Git. Jetons un coup d'œil aux points forts de cette nouvelle version, comprenant des contributions de l'équipe Git de GitLab et de la communauté Git au sens large.

Système de compilation Meson

Pendant longtemps, Git pouvait être compilé en utilisant un système de compilation basé sur des Makefile ou sur Autoconf. Les équipes de développement Git utilisaient principalement le système de compilation basé sur des Makefile. Le système de compilation basé sur Autoconf a donc pris du retard en termes de fonctionnalités et de maintenance. Autre problème : de nombreux développeurs Windows utilisaient des environnements de développement intégrés (IDE) qui ne prenaient pas correctement en charge les systèmes de compilation basés sur des Makefile et Autoconf.

Depuis 2020, il est possible de compiler Git à l'aide de CMake. CMake a permis une meilleure prise en charge de Windows et une meilleure intégration avec les IDE, en particulier Visual Studio. Il a également apporté certaines fonctionnalités des systèmes de compilation modernes, telles que les compilations hors source.

Récemment, il est apparu que la prise en charge de CMake était également à la traîne et que cette option pourrait ne jamais remplacer les deux autres systèmes de compilation de manière satisfaisante. C'est pourquoi Patrick Steinhardt, Git Engineering Manager chez GitLab, a mis en œuvre la prise en charge du système de compilation Meson dans le but de remplacer à terme les systèmes de compilation basés sur Autoconf, CMake et peut-être même les Makefile.

Le nouveau système de compilation basé sur Meson présente les avantages suivants :

  • Il permet aux utilisateurs de trouver facilement les options de compilation disponibles, ce qui est difficile avec les Makefile et CMake.
  • Sa syntaxe est plus simple que celles d'Autoconf et de CMake.
  • Il prend en charge de nombreux systèmes d'exploitation, compilateurs et IDE différents.
  • Il prend en charge les fonctionnalités des systèmes de compilation modernes, telles que les compilations hors source.

Voici un exemple qui montre comment l'utiliser pour compiler Git :

$ cd git             	# go into the root of Git's source code
$ meson setup build/ 	# setup "build" as a build directory
$ cd build           	# go into the "build" directory
$ meson compile      	# actually build Git
$ meson test         	# test the new build
$ meson install      	# install the new build

Plusieurs répertoires de compilation peuvent être configurés à l'aide de meson setup <build_dir>. La configuration de la compilation dans un répertoire de compilation peut être affichée ou modifiée en exécutant meson configure à l'intérieur de ce répertoire.

Vous trouverez plus d'informations sur la façon de compiler Git à l'aide de Meson en haut du fichier meson.build dans le dépôt de code Git. Une comparaison des différents systèmes de compilation pour Git est disponible dans la documentation technique de Git.

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

Git est maintenant exempt de fuites de mémoire (tel que vérifié par la suite de tests)

Dans notre article présentant la version Git 2.47.0 précédente, nous avons évoqué nos efforts constants pour corriger toutes les fuites de mémoire mises en évidence par les tests existants dans le projet. Comme nous l'avons souligné, avant la version 2.47.0 de Git, le projet comptait 223 fichiers de test contenant des fuites de mémoire. Ce nombre avait été réduit à seulement 60.

Nous avons le plaisir d'annoncer que les fuites de mémoire dans ces 60 fichiers de test restants ont été résolues. En conséquence, Git, tel qu'il est vérifié par la suite de tests, est désormais exempt de fuites de mémoire. Il s'agit d'une étape importante menant vers notre objectif de longue date de partitionner les composants internes de Git en une bibliothèque de composants. Cette amélioration aidera également à optimiser l'utilisation de la mémoire avec Git.

Tout test nouvellement ajouté doit désormais être exempt de fuites de mémoire par défaut. Il demeure possible d'exécuter des tests contenant des fuites de mémoire, mais les auteurs devront demander une exception pour cela et justifier pourquoi leur test ne peut pas être exempt de fuites de mémoire.

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

Amélioration des vérifications du bundle URI

Dans notre article présentant la version 2.46.0 de Git, nous avons mentionné certaines corrections du bundle URI apportées par Xing Xin. Une fois ces corrections implémentées, le travail de Xing Xin a rendu possible la vérification complète des récupérations à l'aide de bundles en utilisant le mécanisme fsck comme s'il s'agissait de récupérations standard.

Lors de la validation des récupérations standard, il est possible de spécifier différents niveaux de gravité pour différents problèmes fsck. La gestion de ce qui est accepté ou rejeté dans un dépôt spécifique s'en trouve affinée. Cela n'était auparavant pas possible pour les récupérations à l'aide de bundles.

Pour renforcer encore l'utilité et la sécurité du bundle-uri, nous avons résolu ce problème. Les différents niveaux de gravité indiqués pour différents problèmes fsck sont désormais également utilisés lors de la vérification des récupérations à l'aide de bundles.

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

Ajout des vérifications de cohérence des références

Dans notre article présentant la version 2.47.0 de Git, nous avons mentionné le travail de Jialuo She sur l'ajout d'une nouvelle sous-commande « verify » à git-refs(1) dans le cadre du Google Summer of Code 2024 (GSoC 2024).

Nous avions alors déclaré que l'objectif était à terme d'intégrer cette nouvelle sous-commande à git-fsck(1) afin de fournir un moyen unifié d'exécuter les vérifications de cohérence des dépôts. Jialuo She a décidé de travailler sur ce sujet à l'issue du GSoC.

Le résultat de cet effort est que git-fsck(1) peut maintenant détecter et gérer un certain nombre de problèmes liés aux références, par exemple, lorsque le contenu est de mauvaise qualité, lorsqu'un lien symbolique est utilisé comme référence symbolique ou lorsque la cible d'une référence symbolique ne pointe pas vers une référence valide. Il nous reste toujours à appeler git refs verify via git-fsck(1), et demander à la commande d'effectuer toutes les vérifications non spécifiques au backend dans le processus en cours git-fsck(1). Toutefois, nous avons progressé vers notre objectif final qui est de disposer d'un moyen unifié d'exécuter toutes les vérifications de cohérence des références.

Ce projet a été mené par Jialuo She.

Réutilisation des itérateurs dans les « reftables »

Dans la version Git 2.45.0, le format « reftable » a été introduit en tant que nouveau backend pour stocker des références (principalement des branches et des tags). Si le backend « reftable » ne vous est pas encore familier, n'hésitez pas à consulter notre précédent article de blog consacré à la version 2.45.0 de Git. Nous y présentons ce nouveau format, ainsi que notre guide intitulé Format reftable de Git : guide pour les débutants.

Nous avons depuis continué à améliorer ce backend. Récemment, nous nous sommes concentrés sur l'amélioration de ses performances en réutilisant certains itérateurs internes lors de la lecture de références aléatoires. Avant ces changements, la lecture d'une seule référence nous obligeait à créer un tout nouvel itérateur, à le déplacer au bon endroit dans les tables respectives, puis à lire la valeur suivante. Cette démarche se révèle assez inefficace lors de la lecture en succession rapide de nombreuses références. Nous ne créons désormais plus qu'un seul itérateur et le réutilisons pour lire plusieurs références, ce qui permet d'alléger le travail effectué.

Les performances dans un certain nombre de cas d'utilisation liés aux « reftables » sont par conséquent améliorées. Nous avons notamment mesuré une accélération de 7 % lors de la création de nombreuses références dans une transaction qui effectue de nombreuses lectures aléatoires. Notre travail ouvre de plus la porte à davantage d'optimisations, car nous pouvons continuer à réutiliser une plus grande quantité d'états conservés dans les itérateurs.

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

Prise en charge des reflogs dans git-refs migrate

Suite à l'introduction du backend « reftable » dans Git 2.45.0, nous avons travaillé sur des outils pour migrer les backends de gestion des références dans Git 2.46.0. Il s'agissait d'ajouter une nouvelle sous-commande migrate à git-refs(1).

Notre article consacré à Git 2.46.0 décrivait cette tâche et mentionnait certaines limitations encore présentes. L'article soulignait notamment les points suivants :

« Les reflogs dans un dépôt font partie du backend de gestion des références et nécessitent également une migration lors du changement de format. Malheureusement, l'outil n'est pas encore capable de convertir les reflogs entre les backends « fichiers » et les backends « reftable ». »

Nous sommes heureux d'annoncer que nous avons levé cette limitation dans la version Git 2.48.0. Les reflogs peuvent désormais également être migrés avec git refs migrate. L'outil de migration n'est pas encore capable de gérer un dépôt contenant des arbres de travail séparés (« worktrees »), mais il s'agit de la dernière limitation restante. Si vous n'utilisez pas d'arbres de travail séparés (« worktrees »), vous pouvez déjà utiliser le backend « reftable » dans vos dépôts existants.

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

Optimisation du filtre des références

Le sous-système 'ref-filter' est un code de mise en forme utilisé par des commandes telles que git for-each-ref, git branch et git tag pour trier, filtrer, mettre en forme et afficher les informations relatives aux références Git.

À mesure que les dépôts se développent, la quantité de références qu'ils contiennent peut devenir astronomique. C'est pourquoi nous avons du travail à faire non seulement pour améliorer les backends qui stockent des références, comme le backend « reftable » (voir ci-dessus), mais aussi pour optimiser le code de mise en forme, comme le sous-système 'ref-filter'.

Nous avons récemment trouvé une méthode pour éviter de mettre temporairement les références en mémoire tampon et de les traiter chacune plusieurs fois dans le code de filtrage des références. Désormais, celles-ci sont traitées directement dans l'ordre de tri fourni par les backends. Cette amélioration réduit la consommation de mémoire et accélère certaines commandes, pouvant les rendre jusqu'à 770 fois plus rapides dans certains cas.

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

En savoir plus

Cet article n'a mis en évidence que quelques-unes des contributions apportées par GitLab et la communauté Git au sens large pour cette nouvelle version.

Vous pouvez approfondir ce sujet en lisant l'annonce officielle du projet Git et en consultant nos précédents articles de blog sur les nouvelles versions de Git.

Votre avis nous intéresse

Cet article de blog vous a plu ou vous avez des questions ou des commentaires ? Partagez vos réflexions en créant un nouveau sujet dans le forum de la communauté GitLab. Partager votre expérience

Lancez-vous dès maintenant

Découvrez comment la plateforme DevSecOps unifiée de GitLab peut aider votre équipe.

Commencer un essai gratuit

Découvrez le forfait qui convient le mieux à votre équipe

En savoir plus sur la tarification

Découvrez ce que GitLab peut offrir à votre équipe

Échanger avec un expert