Après deux mois de développement, la version 2.51 du système de gestion décentralisée de code source Git est désormais disponible. Git se distingue par sa haute performance et offre des outils pour le développement non linéaire basés sur le branchement et la fusion de branches. Pour garantir l'intégrité de l'historique et la protection contre les modifications rétroactives, Git utilise un hachage implicite de tout l'historique précédent dans chaque commit, ainsi que l'authentification par signatures numériques des développeurs pour certains tags et commits. Le code de Git est distribué sous la licence GPLv2+.
Comparée à la version précédente, la nouvelle version inclut 506 modifications effectuées par 91 développeurs (dont 21 ont participé au développement de Git pour la première fois). Les principales nouveautés (1, 2, 3) :
- Les performances des commandes « git push » et « git fetch » dans les dépôts avec un grand nombre de références ont été améliorées. Cette accélération est due à la mise à jour des références en mode groupé, où plusieurs références sont traitées dans une seule transaction, au lieu de créer une transaction distincte pour chaque mise à jour de référence. Cette optimisation a considérablement augmenté la vitesse de backend « reftable », qui surpasse désormais le backend « files » en performance. Par exemple, dans un dépôt de test contenant 10 000 références, la performance de « git fetch » avec le backend « reftable » a été 22 fois meilleure, tandis qu'avec le backend « files », elle n'a augmenté que de 1,25 fois. Pour « git push », les gains ont été de 18 et 1,21 fois, respectivement.
- Une nouvelle méthode d'emballage des parties du dépôt en fichiers pack, non liées au suivi des objets inaccessibles dans lesquels il n'existe pas de références (aucune branche ou tag ne fait référence à eux), a été proposée. Les informations concernant les objets inaccessibles sont stockées dans des fichiers pack distincts (« cruis packs »), ce qui nécessite leur inclusion dans les index multi-pack MIDX pour englober les objets initialement inaccessibles, mais qui sont devenus accessibles après un commit faisant référence à eux.
Dans la nouvelle version, lors de la réemballage des fichiers pack, la conservation des copies supplémentaires des objets accessibles, uniquement stockés dans des fichiers cruft, a été intégrée. Ce changement garantit que l'ensemble de fichiers pack, utilisé pour stocker des objets accessibles, ne contient pas d'objets faisant référence à d'autres objets stockés en dehors de cet ensemble. Pour exclure le contenu inaccessible des fichiers cruft dans les index multi-pack (MIDX), un réglage "repack.MIDXMustContainCruft" a été proposé, permettant de réduire considérablement la taille de tels index. L'activation de ce réglage dans le dépôt GitHub a permis de réduire la taille des index MIDX de 38 %, d'accélérer l'écriture dans les index MIDX de 35 % et d'améliorer la performance de lecture de 5 %.
- L'option "—path-walk" a été ajoutée à la commande « git pack-objects », permettant un nouveau mode de collecte d'informations sur les objets lors du réemballage des fichiers pack. Au lieu de parcourir les objets dans l'ordre des révisions, en utilisant le mode "—path-walk", les objets sont parcourus à travers les chemins de fichiers, ce qui permet d'emballer en une seule fois tous les objets ayant le même chemin de fichier. Cette approche permet d'éviter l'heuristique utilisant le hachage pour déterminer la relation entre un objet et son chemin de fichier, ainsi que d'éliminer le tri des objets avant l'emballage. En utilisant le mode "—path-walk", la taille des fichiers pack générés est significativement inférieure à celle obtenue en groupant les objets par hachages.
- Un format a été défini pour l'échange des états sauvegardés de l'arborescence de travail et des index dans le dépôt, créés à l'aide de la commande « git stash ». Ce nouveau format permet de coder les changements sauvegardés (entrées de stash) sous forme de séquence de commits. Les sous-commandes « git stash import » et « git stash export » sont proposées pour importer et exporter ces états sauvegardés, pouvant être utilisés pour transférer des états d'un système à un autre et pour effectuer des opérations de push ou pull sur ces états comme s'il s'agissait de branches ou de tags ordinaires. git stash export —to-ref refs/stashes/my-stash git push origin refs/stashes/my-stash … git fetch origin ‘+refs/stashes/*:refs/stashes/*’ git stash import refs/stashes/my-stash
- Dans la commande «git cat-file», qui affiche le contenu des objets spécifiés, des options «—batch» et «—batch-check» ont été mises en œuvre pour permettre l'affichage d'informations sur les objets manquants (par exemple, en raison de la corruption d'un dépôt) et des sous-modules. Auparavant, en spécifiant le chemin d'une sous-module, la commande «git cat-file —batch-check» affichait «missing», mais maintenant elle montrera l'identifiant de l'objet.
- La commande «git log» utilise des optimisations basées sur des filtres de Bloom pour accélérer la recherche dans l'historique des changements lorsque des filtres avec plusieurs chemins de fichiers sont spécifiés, par exemple, «git log — path/to/a path/to/b».
- Les commandes «git switch» et «git restore» ont été stabilisées, elles étaient considérées comme expérimentales depuis 2019. Ces commandes sont présentées comme les équivalents modernes de «git checkout», séparant des fonctionnalités peu liées de cette commande, telles que la manipulation de branches (changement et création) et la restauration de fichiers dans le répertoire de travail.
- La commande «git whatchanged», équivalente à «git log —raw», a été déclarée obsolète et prévue pour suppression dans la branche Git 3.0.
- L'option «—start-after» a été ajoutée à la commande «git for-each-ref», qui peut être utilisée avec l'option «—count» pour organiser la sortie paginée.
- Les commandes «git merge» et «git pull» ont reçu l'option «—compact-summary» pour utiliser un format compact de résumé des changements au lieu du format diffstat.
- L'utilisation du mot-clé «bool», introduit dans la norme C99, est désormais autorisée dans la base de code Git. Certaines fonctionnalités de C99, utilisées expérimentalement dans Git, sont également documentées (par exemple, il est prévu d'autoriser l'utilisation des constructions «(struct foo){ .member = value };» d'ici 2026). Un compilateur prenant en charge C99 est obligatoire pour Git depuis 2021, mais les fonctionnalités de la norme C99 sont intégrées très progressivement pour maintenir la compatibilité avec les compilateurs qui ne prennent en charge que partiellement cette norme.
- Des modifications ont été apportées aux règles d'acceptation des patches, permettant l'envoi de patches sous un pseudonyme et non seulement sous le vrai nom du développeur. Ce changement est conforme aux règles d'acceptation des patches dans le noyau Linux.
- La liste des modifications incompatibles a été mise à jour et sera appliquée dans la branche Git 3.0. Parmi les changements importants de la prochaine version de Git 3.0, on note le passage par défaut à des identifiants d'objets basés sur l'algorithme de hachage SHA-256 lors de l'initialisation de nouveaux référentiels et l'utilisation du format « reftable » pour stocker dans le référentiel des liens vers des branches et des tags (utilisant un stockage par blocs du projet JGit, optimisé pour conserver un très grand nombre de liens).
Source : opennet.ru
