Après trois mois de développement, la version du système de gestion décentralisé des versions de code Git 2.52 est maintenant disponible. Git se distingue par sa haute performance et propose des outils pour le développement non linéaire, basés sur la création et la fusion de branches. Pour garantir l'intégrité de l'historique et sa résistance aux modifications rétroactives, une hachage implicite de l'ensemble de l'historique précédent est utilisé dans chaque commit, ainsi que l'authentification par signature numérique des développeurs pour certains tags et commits. Le code de Git est distribué sous la licence GPLv2+.
Comparé à la version précédente, 637 changements ont été intégrés dans cette nouvelle version, préparés par la participation de 94 développeurs (33 ayant participé au développement de Git pour la première fois). Principales nouveautés (1, 2, 3):
- Ajout de la commande «git last-modified» pour afficher la liste des fichiers dans la révision spécifiée et des commits à travers lesquels les dernières modifications ont été apportées à chacun de ces fichiers. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c
- Ajout de la commande «git repo» pour effectuer des actions liées à l'extraction d'informations du dépôt. Deux sous-commandes ont été proposées : «git repo info» et «git repo structure», qui affichent des informations sur les paramètres du dépôt et des détails sur la structure du dépôt (par exemple, il est possible de connaître le nombre de références et d'objets dans le dépôt). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Structure du dépôt | Valeur | | ——————— | —— | | * Références | | | * Compte | 1983 | | * Branches | 4 | | * Tags | 1125 | | * Distants | 854 | | * Autres | 0 | | | | | * Objets accessibles | | | * Compte | 518955 | | * Commits | 77469 | | * Arbres | 188865 | | * Blobs | 251631 | | * Tags | 990 |
- Trois sous-commandes ont été ajoutées à la commande «git refs», unifiant des opérations de bas niveau qui étaient éparpillées et se chevauchant sur les références (git for-each-ref, git show-ref, git update-ref et git pack-refs) :
- «git refs optimize» — optimisation du backend de stockage des références (analogique à «git pack-refs»).
- «git refs list» — affichage de la liste de toutes les références (analogue à «git for-each-ref» ou «git show-ref»).
- «git refs exists» — vérification de l'existence d'une référence (équivalent à «git show-ref —exists»).
- Le format d'exportation ou d'importation de l'historique des commits a été étendu avec la possibilité de travailler avec des signatures cryptographiques, utilisant à la fois des identifiants d'objets basés sur l'algorithme SHA-1 et sur SHA-256. L'équipe « git fast-import » a implémenté la prise en charge du traitement des tags signés analogiquement aux commits signés. Des options « —signed-commits= » et « —signed-tags= » ont été ajoutées pour gérer le traitement des commits et tags signés lors de l'importation (le mode peut prendre des valeurs verbatim, warn-verbatim, warn-stri, strip ou abort).
- L'équipe « git maintenance » a ajouté le support d'une nouvelle stratégie « géométrique » (« git config set maintenance.strategy geometric »), permettant de réduire le temps de maintenance des grands monorepositories. Par rapport à la stratégie précédente, qui utilise la logique de l'équipe « git gc », la nouvelle stratégie évite la réemballage de tous les objets et exclut les opérations excessivement gourmandes en ressources, telles que la fusion de tous les fichiers pack (dans la mesure du possible, la fusion se fait par morceaux et sans nettoyer les objets supprimés).
- La commande « git sparse-checkout clean » a été ajoutée pour simplifier la restauration de l'état du répertoire de travail, en supprimant les fichiers qui ne correspondent pas à la nouvelle définition de sparse-checkout et qui ne doivent pas être présents dans la copie locale selon les paramètres actuels de sparse-checkout.
- Pour simplifier le code et améliorer sa maintenance, un refactoring a été réalisé pour réduire l'utilisation de la variable globale the_repository.
- L'application des filtres de Bloom, une structure probabiliste pour vérifier l'appartenance à un ensemble, qui admet une fausse détection d'un élément manquant mais exclut le risque de manquer un élément existant, a été élargie. Les filtres de Bloom sont désormais utilisés pour accélérer la recherche dans l'historique des modifications en spécifiant des masques dans les chemins de fichiers, par exemple, « foo/bar/*/baz ».
- Les performances de la commande « git describe » ont été améliorées de 30 %, grâce à l'utilisation d'une file d'attente prioritaire. Les opérations de renommage de liens dans « git remote rename » ont été accélérées. L'application des index dans « git ls-files » a été élargie. Le fonctionnement de la commande « git log -L » a été considérablement accéléré, grâce à l'élimination des comparaisons superflues à trois niveaux lors du traitement des fusions de commits. Des optimisations ont également été apportées à la bibliothèque xdiff.
- Une option facultative est désormais disponible pour l'utilisation d'implémentations en langage Rust pour certaines fonctions internes, telles que l'encodage et le décodage de valeurs entières à longueur variable. Par défaut, le code en Rust n'est pas utilisé et pour l'activer, il est nécessaire de spécifier le drapeau de compilation WITH_RUST. À l'avenir, une refonte de composants internes plus importants de Git en Rust est prévue, et l'ajout de Rust parmi les dépendances de compilation obligatoires dans Git 3.0 est envisagé.
- La liste des modifications incompatibles a été mise à jour, qui seront appliquées dans la branche Git 3.0. Dans Git 3.0, il a été décidé de changer la configuration init.defaultBranch par défaut à « main », c'est-à-dire que dans les dépôts créés avec la commande « git init », la branche par défaut sera nommée « main » au lieu de « master ». Il est également à noter que le passage par défaut aux identifiants d'objets basés sur l'algorithme de hachage SHA-256 lors de l'initialisation de nouveaux dépôts a été adopté. Pour faciliter la portabilité entre les dépôts utilisant des identifiants d'objets basés sur SHA-1 et SHA-256, il est désormais possible d'effectuer des opérations de push et pull à partir d'un dépôt utilisant un autre algorithme de hachage, même si l'on se trouve dans un dépôt avec un seul algorithme de hachage.
Source : opennet.ru
