Le système de gestion de versions distribué Git 2.55 est disponible, ajoutant l'écriture MIDX incrémentielle, la correction de l'historique et la prise en charge de fsmonitor sous Linux

Le système de gestion de versions distribué Git 2.55 est disponible, ajoutant l'écriture MIDX incrémentielle, la correction de l'historique et la prise en charge de fsmonitor sous Linux

Git 2.55 a été publié avec une mise à jour majeure de la gestion des dépôts grâce à l’écriture incrémentielle d’index multi-packs. Activée avec la commande git repack --write-midx=incremental, cette fonctionnalité permet à Git d’ajouter de nouvelles couches d’index pour les packs nouvellement créés au lieu de réécrire l’intégralité du fichier MIDX. La commande expérimentale git history bénéficie également d’une nouvelle sous-commande fixup, permettant aux utilisateurs d’intégrer les modifications mises en attente dans un commit antérieur et de réappliquer les commits ultérieurs par-dessus. Git 2.55 améliore également le flux de travail et les performances dans plusieurs domaines.

Git est un système logiciel de contrôle de version distribué capable de gérer les versions de code source ou de données. Il est souvent utilisé pour contrôler le code source par des programmeurs qui développent des logiciels en collaboration. Il a été créé à l’origine par Linus Torvalds pour le contrôle de version dans le cadre du développement du noyau Linux. Les objectifs de conception de Git incluent la vitesse, l’intégrité des données et la prise en charge de flux de travail distribués et non linéaires — des milliers de branches parallèles s’exécutant sur différents ordinateurs.

Git est le système de contrôle de version le plus couramment utilisé par les développeurs de logiciels. Il s’agit du système de contrôle de version distribué le plus populaire, près de 95 % des développeurs le désignant comme leur principal système de contrôle de version en 2022. C’est l’outil de gestion de code source le plus largement utilisé parmi les développeurs professionnels. Plusieurs plateformes de développement proposent des services de dépôts Git, notamment GitHub, SourceForge, Bitbucket et GitLab.

Récemment, Git 2.55 a été publié avec une mise à jour majeure de la gestion des dépôts grâce à l’écriture incrémentielle d’index multi-packs. Activée avec la commande git repack --write-midx=incremental, cette fonctionnalité permet à Git d’ajouter de nouvelles couches d’index pour les packs nouvellement créés au lieu de réécrire l’intégralité du fichier MIDX. Lorsqu’elle est combinée au reconditionnement géométrique, Git peut utiliser une compaction basée uniquement sur les métadonnées pour maintenir l’efficacité des chaînes MIDX, en compactant les couches en fonction de repack.midxSplitFactor et en conservant une croissance logarithmique par rapport à la taille du dépôt.

La commande expérimentale git history bénéficie également d’une nouvelle sous-commande fixup, permettant aux utilisateurs d’intégrer les modifications mises en attente dans un commit antérieur et de réappliquer les commits ultérieurs par-dessus. Cela facilite la modification d’anciens commits sans avoir à créer manuellement des commits de correction ni à exécuter un rebase `autosquash`. La commande reste prudente : elle nécessite un arbre de travail et s’interrompt en cas de conflits.

Git 2.55 améliore également le flux de travail et les performances dans plusieurs domaines. Les hooks basés sur la configuration peuvent désormais s’exécuter en parallèle lorsqu’ils sont activés, tandis que les hooks qui dépendent d’un état partagé continuent de s’exécuter en série. La génération du bitmap d’accessibilité est plus rapide : un benchmark sur un grand dépôt est passé d’environ 612 secondes à 294 secondes. De plus, Linux prend désormais en charge le moniteur de système de fichiers intégré à Git via inotify, ce qui contribue à accélérer des commandes telles que git status lorsque les limites de surveillance du système sont suffisantes.


Voici un extrait de l'annonce de Git 2.55 :

Les points forts de Git 2.55

Le projet open source Git vient de publier la version 2.55 de Git, qui intègre des fonctionnalités et des corrections de bogues apportées par plus de 100 contributeurs, dont 33 nouveaux. Notre dernier point sur les nouveautés de Git remonte à la sortie de la version 2.54.

Pour célébrer cette toute dernière version, voici un tour d’horizon proposé par GitHub des fonctionnalités et modifications les plus intéressantes introduites depuis la dernière mise à jour.

Recompression avec des index multi-pack incrémentiels

Les lecteurs fidèles de cette série se souviendront peut-être de nos articles consacrés aux index multi-pack incrémentiels et aux bitmaps d’accessibilité multi-pack incrémentiels. Au cas où vous auriez besoin d’un petit rappel, en voici un résumé.

Git stocke le contenu de votre dépôt sous forme d’objets individuels : commits, arborescences et blobs. Ces objets se trouvent généralement dans des fichiers pack, qui sont des collections compressées d’objets. À chaque fichier pack correspond un index de pack qui permet à Git de localiser rapidement n’importe quel objet à l’intérieur du pack. Mais les dépôts volumineux ne comportent généralement pas un seul fichier pack : au fil du temps, les opérations de récupération, de push, les tâches de maintenance et les reconditionnements peuvent laisser derrière eux de nombreux packs.

Un index multi-pack (ou MIDX) fournit à Git un index unique couvrant plusieurs packs. Au lieu d’ouvrir et de rechercher l’index individuel de chaque pack, Git peut interroger le MIDX pour savoir quel pack contient un objet donné et à quel offset. Cela s’avère particulièrement utile pour les dépôts volumineux, et c’est l’un des piliers de la stratégie de maintenance des dépôts de GitHub.

Comme nous l’avons vu lors de l’introduction du format MIDX incrémental dans Git 2.47, un dépôt peut stocker son MIDX sous la forme d’une chaîne de couches plutôt que sous la forme d’un MIDX unique couvrant tous les packs. Un MIDX à fichier unique est simple et efficace à lire, mais il présente un coût de maintenance important ; comme ce fichier inclut tous les packs qu’il couvre, même une petite mise à jour peut nécessiter une écriture volumineuse dans un dépôt déjà volumineux.

Les MIDX incrémentiels résolvent ce problème en stockant une chaîne de couches MIDX. Chaque couche couvre un ensemble de packs, et le fichier de la chaîne enregistre l’ordre de ces couches. L’ajout d’une nouvelle couche à l’extrémité de la chaîne n’invalide pas les couches plus anciennes ; Git peut ainsi indexer les packs nouvellement créés sans réécrire un fichier MIDX unique couvrant l’intégralité du dépôt.

Git 2.55 apprend à la commande git repack à écrire directement ces chaînes MIDX incrémentielles :



Sans aucune autre option, ce mode est en écriture seule : Git écrit une nouvelle couche pour les paquets créés par le repack et laisse les couches existantes telles quelles. Cela s’avère déjà utile lorsque vous souhaitez minimiser la quantité de métadonnées réécrites lors d’une opération de maintenance.

Mais une chaîne en ajout seul ne peut pas s’allonger indéfiniment. Si chaque opération de maintenance ajoute une nouvelle couche, la chaîne elle-même finit par devenir ce que vous devez maintenir. Git 2.55 prend également en charge la combinaison de l’option --write-midx=incremental avec le reconditionnement géométrique :



Lorsque ces modes sont utilisés conjointement, chaque repack crée une nouvelle couche d’extrémité, puis détermine si les couches adjacentes doivent être compactées ensemble. La règle par défaut est contrôlée par repack.midxSplitFactor : si le nombre cumulé d’objets dans les couches les plus récentes devient suffisamment important par rapport à la couche immédiatement antérieure, Git fusionne ces couches en une seule couche de remplacement. Sinon, les couches plus anciennes restent inchangées.

À un niveau général, l’algorithme fonctionne comme suit. Ci-dessous, N désigne la valeur de repack.midxNewLayerThreshold, et f désigne la valeur de repack.midxSplitFactor :

1. Sélectionnez les paquets non MIDX comme candidats au reconditionnement géométrique. Si la couche MIDX de pointe comporte au moins N paquets, incluez-les également parmi les candidats.

2. Appliquez la règle habituelle de regroupement géométrique à cet ensemble de candidats, puis écrivez une nouvelle couche MIDX de pointe couvrant les paquets obtenus.

3. Compactez les couches MIDX adjacentes lorsque le nombre cumulé d’objets de la ou des couches les plus récentes dépasse 1/f du nombre d’objets de la couche immédiatement plus profonde.

Pour comprendre comment les éléments s’articulent, prenons l’exemple d’un référentiel disposant déjà d’une chaîne MIDX incrémentielle. Les couches les plus anciennes se trouvent à gauche, et la couche d’extrémité à droite. Parallèlement, l’activité normale du référentiel continue de produire de nouveaux paquets. Ces paquets ne sont encore couverts par aucune couche MIDX, ce qui signifie que la prochaine opération de maintenance comporte deux tâches : déterminer ce qu’il faut réorganiser, et décider quelle partie de la chaîne MIDX doit être réécrite.


En règle générale, ces packs non couverts par MIDX sont les seuls candidats au reconditionnement géométrique : Git peut écrire un nouveau pack et une nouvelle couche MIDX d’extrémité sans perturber aucune couche existante. La figure ci-dessous illustre le cas le plus intéressant, où la couche d’extrémité actuelle a accumulé suffisamment de packs pour atteindre le seuil configuré repack.midxNewLayerThreshold. Une fois ce seuil atteint, les packs de la couche d’extrémité peuvent rejoindre les packs nouvellement écrits en tant que candidats au reconditionnement géométrique.

Le « repacking géométrique » pose alors une question locale concernant les nouveaux paquets candidats. Le « repacking géométrique » pose alors une question locale concernant les nouveaux paquets candidats : le paquet situé immédiatement à gauche d’un suffixe de paquets (P) est-il suffisamment grand pour préserver la progression géométrique si Git regroupe 𝒫 ? Dans la première tentative ci-dessous, 𝒫 contient le plus petit pack de la couche de pointe actuelle ainsi que les nouveaux packs non traités par MIDX. Mais le pack situé à gauche de la scission ne contient que 30 000 objets, ce qui est inférieur au double de la taille de
𝒫 ; cette scission est donc trop décalée vers la droite.


Git déplace donc la division d’un pack en amont et repose la même question. Désormais, 𝒫 inclut un pack supplémentaire provenant de la couche de pointe. Le pack situé immédiatement à gauche contient 100 000 objets, soit au moins deux fois la taille du suffixe sélectionné. C’est à ce moment-là que l’invariant géométrique s’applique, ce qui permet à Git de regrouper précisément ces packs dans un nouveau pack.


Après avoir écrit ce nouveau pack, Git écrit une nouvelle couche MIDX de pointe par-dessus le pack survivant de la couche de pointe précédente et le pack regroupé nouvellement écrit. À ce stade, les fichiers de pack sont en bon état, mais la chaîne MIDX peut encore avoir accumulé trop de petites couches adjacentes. Git applique le même principe « le plus récent par rapport à l’ancien » aux couches MIDX elles-mêmes : si la couche la plus récente est suffisamment grande par rapport à sa voisine, il compacte leurs métadonnées en une couche de remplacement.


Cette étape de compactage concerne délibérément uniquement les métadonnées. Git ne reconditionne pas les objets de ces couches ; il écrit une nouvelle couche MIDX qui couvre les mêmes fichiers pack. Il examine ensuite la couche immédiatement antérieure. Ici, la couche compactée est encore plus petite que la moitié de la couche plus profonde, donc Git s’arrête. La couche plus ancienne reste intacte, ce qui est la propriété clé qui permet à cette maintenance de rester incrémentielle.


Le résultat est un compromis entre deux extrêmes. Un fichier MIDX unique minimise la complexité des recherches, mais peut nécessiter d’importantes réécritures lors de la maintenance. Un MIDX incrémental purement « en ajout seul » minimise chaque écriture mais permet à la chaîne de s’allonger sans limite. Le reconditionnement incrémental géométrique maintient le nombre de couches à un niveau logarithmique par rapport au nombre total d’objets, tout en garantissant que les couches les plus récentes et les plus petites soient réécrites plus souvent que les plus anciennes et les plus volumineuses.

Ce mécanisme s’intègre également au système de reconditionnement existant de Git. Les paquets nouvellement écrits qui ne sont pas encore couverts par la chaîne MIDX sont toujours candidats au reconditionnement géométrique ; les paquets situés dans les couches MIDX plus profondes ne sont pas modifiés. Les paquets de la couche MIDX de pointe ne rejoignent l’ensemble des candidats qu’une fois que cette couche contient au moins repack.midxNewLayerThreshold paquets. Si la couche de pointe est encore inférieure à ce seuil, Git évite complètement de la modifier et se contente d’ajouter une nouvelle couche pour les paquets nouvellement écrits.

Pour les dépôts qui reçoivent un flux constant de nouveaux objets, cela signifie que la maintenance de routine peut mettre à jour les métadonnées des paquets du dépôt de manière incrémentielle, sans obliger chaque opération de maintenance à réécrire un seul MIDX couvrant l’ensemble du magasin d’objets.

Corriger des commits antérieurs avec git history:

Quiconque a déjà peaufiné une série de commits avant de la soumettre à révision a probablement déjà vécu cette situation : vous remarquez qu’une modification dans votre arborescence de travail appartient en réalité à un commit antérieur, et non à l’extrémité de la branche.

Aujourd’hui, une méthode courante pour gérer cela consiste à créer un commit de correction (fixup), puis à l’autosquasher :



Cela fonctionne, mais cela vous oblige à détailler le mécanisme plutôt que l’intention. Git 2.55 s’appuie sur la commande expérimentale git history, introduite dans Git 2.54, en ajoutant une nouvelle sous-commande fixup. Elle applique les modifications actuellement mises en attente dans l’index à un commit antérieur :



Voici un petit exemple. Le premier commit a introduit une recette de crêpes, suivie de quelques autres commits par-dessus. Plus tard, on se rend compte qu’il manquait du sirop d’érable dans la recette. Après avoir mis en attente cette modification d’une ligne, la commande git history fixup <commit> l’intègre au commit de la recette d’origine et réapplique les commits descendants par-dessus. Ici, la modification mise en attente fait partie intégrante du commit cible lui-même. Par défaut, le commit cible conserve son message et son auteur, sauf si vous passez l’option --reedit-message, et Git réécrit les commits suivants afin que la branche aboutisse à un historique équivalent avec la correction à la bonne place.

Comme le reste de git history, cette commande est encore expérimentale. Elle est également volontairement prudente. Comme fixup lit à partir de l’index, elle nécessite un arbre de travail et ne peut pas fonctionner dans un dépôt nu ; si l’application de la modification mise en attente devait produire un conflit, la commande s’interrompt plutôt que de vous laisser au milieu d’une réécriture avec état.

Source : Annonce de Git 2.55

Et vous ?

Pensez-vous que cette annonce est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Le système de gestion de versions distribué Git 2.54 est disponible et introduit la commande « git history » et des hooks améliorés pour une meilleure gestion des dépôts

Git va changer le nom par défaut de sa branche « master » en « main » dans la version 3.0, prévue pour fin 2026, afin de promouvoir un langage inclusif dans le contexte des changements sociaux de 2020

Linus Torvalds célèbre le 20e anniversaire de Git. Est-il plus célèbre que Linux ?