Après trois mois de développement, la version stable du système de gestion décentralisé Git 2.52 est maintenant disponible. Git se distingue par sa haute performance et offre des outils de 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 résister aux modifications rétroactives, il 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, cette nouvelle version comprend 637 modifications, réalisées par 94 développeurs (33 ayant participé à Git pour la première fois). Les principales nouveautés (1, 2, 3) :
- Une nouvelle commande « git last-modified » a été ajoutée pour afficher la liste des fichiers dans une révision spécifiée et des commits par 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
- La commande « git repo » a été ajoutée pour effectuer des actions liées à l'extraction d'informations d'un dépôt. Deux sous-commandes ont été proposées : « git repo info » et « git repo structure », qui affichent des informations sur la configuration du dépôt et des détails sur la structure du dépôt (par exemple, 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 | | * Remotes | 854 | | * Autres | 0 | | | | * Objets atteignables | | | * Compte | 518955 | | * Commits | 77469 | | * Arbres | 188865 | | * Blobs | 251631 | | * Tags | 990 |
- La commande « git refs » a été enrichie de trois sous-commandes qui unifient des opérations de bas niveau disparates et chevauchantes sur les références (git for-each-ref, git show-ref, git update-ref et git pack-refs) :
- « git refs optimize » — optimisation de l'arrière-plan de stockage des références (similaire à « git pack-refs »).
- « git refs list » — affichage d'une liste de toutes les références (similaire à « git for-each-ref » ou « git show-ref »).
- « git refs exists » — vérification de l'existence d'une référence (similaire à « git show-ref --exists »).
- Le format d'exportation ou d'importation de l'historique des commits a été étendu par la possibilité de travailler avec des signatures cryptographiques, utilisant des identifiants d'objets basés sur l'algorithme SHA-1 ainsi que sur SHA-256. La commande « git fast-import » a mis en œuvre le support du traitement des tags signés, à l'instar des 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 les valeurs verbatim, warn-verbatim, warn-stri, strip ou abort).
- La commande « 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 monorepos. Par rapport à l'ancienne stratégie, qui utilisait une logique similaire à celle de la commande « git gc », la nouvelle stratégie évite de réemballer tous les objets et exclut les opérations trop gourmandes en ressources, comme la fusion de tous les fichiers pack (la fusion se fait par parties autant que possible et sans nettoyage des objets supprimés).
- La commande « git sparse-checkout clean » a été ajoutée pour faciliter 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 devraient pas être présents dans la copie locale selon les paramètres actuels de sparse-checkout.
- Pour alléger la base de code et simplifier la maintenance, un refactoring a été effectué 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, a été étendue. Ces filtres permettent une fausse déclaration d'un élément manquant mais évitent de manquer un élément existant. Les filtres de Bloom sont désormais utilisés pour accélérer la recherche dans l'historique des modifications lors de la spécification de 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 de priorités. Les opérations de renommage des références dans « git remote rename » ont été accélérées. Dans « git ls-files », l'application des index a été étendue. Le fonctionnement de la commande « git log -L » a été considérablement optimisé en éliminant les comparaisons superflues à trois niveaux lors du traitement des fusions de commits. Des optimisations ont également été apportées à la bibliothèque xdiff.
- Il est désormais possible d'utiliser des implementations en Rust pour certaines fonctions internes, telles que l'encodage et le décodage des valeurs entières de longueur variable. Par défaut, le code Rust n'est pas utilisé et nécessite d'activer l'option de compilation WITH_RUST. À l'avenir, on s'attend à ce que des composants internes significatifs de Git soient réécrits en Rust et que Rust devienne une dépendance de compilation requise dans Git 3.0.
- 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 à la valeur «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». On note également 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. Pour faciliter la portabilité entre les dépôts avec des identifiants d'objets basés sur les hachages SHA-1 et SHA-256, il est désormais possible d'effectuer des opérations de push et pull d'un dépôt utilisant un algorithme de hachage différent.
Source : opennet.ru
