🥇 Sortie du système de gestion de versions distribué Git 2.31

La version distribuée du système de gestion de code source Git 2.31 est maintenant disponible. Git est l'un des systèmes de gestion de versions les plus populaires, fiables et performants, offrant des outils flexibles pour le développement non linéaire, basés sur la branche et la fusion. Pour assurer l'intégrité de l'historique et la résistance aux modifications rétroactives, un hachage implicite de toute l'historique précédente est effectué dans chaque commit, et il est également possible de vérifier les signatures numériques des développeurs pour certains tags et commits.

Comparé à la version précédente, cette nouvelle version comporte 679 changements préparés par 85 développeurs, dont 23 ont participé au développement pour la première fois. Les principales nouveautés :

Ajoutée la commande « git maintenance », qui permet d'effectuer des tâches périodiques sur des systèmes ne prenant pas en charge cron. Par exemple, avec cette nouvelle commande, il est possible d'organiser le lancement périodique du processus de compression du dépôt, sans avoir à attendre la fin du blocage du dépôt lors de l'exécution automatique de la compression pendant le lancement de diverses commandes. La commande « git maintenance » permet d'effectuer des optimisations et des opérations de maintien de la structure optimale du dépôt en arrière-plan, sans bloquer la session interactive – une tâche de préchargement des nouveaux objets du dépôt distant est exécutée une fois par heure et le processus de compression du dépôt est lancé chaque nuit.
Ajoutée la prise en charge de la tenue d'un index inversé (revindex) sur disque pour les fichiers pack. Rappelons que Git stocke toutes les données sous forme d'objets, qui sont placés dans des fichiers distincts. Pour améliorer l'efficacité du travail avec le dépôt, les objets sont également placés dans des fichiers pack, où les informations sont présentées sous forme d'un flot d'objets se suivant l'un l'autre (un format similaire est utilisé lors du transfert d'objets avec les commandes git fetch et git push). Pour chaque fichier pack, un fichier d'index (.idx) est créé, permettant de déterminer très rapidement le décalage dans le fichier pack où cet objet est stocké en fonction de l'identifiant de l'objet. L'index inversé (.rev) introduit dans Git 2.31 vise à optimiser le processus de détermination de l'identifiant de l'objet à partir des informations sur l'emplacement de l'objet dans le fichier pack.
Auparavant, cette transformation était effectuée à la volée lors de l'analyse du fichier pack et était stockée uniquement en mémoire, ce qui ne permettait pas de réutiliser de tels index et obligeait à générer un index à chaque fois. L'opération de construction d'index consiste à construire un tableau de paires «objet-position» et à le trier par position, ce qui peut prendre beaucoup de temps pour de grands fichiers pack.

Par exemple, l'opération d'affichage du contenu des objets, qui utilise un index direct, était 62 fois plus rapide que l'opération affichant la taille des objets, pour laquelle les données de liaison de la position à l'objet n'étaient pas indexées. Après l'utilisation d'un index inverse, ces opérations prenaient maintenant un temps à peu près équivalent. Les index inverses permettent également d'accélérer les opérations d'envoi d'objets lors de l'exécution des commandes fetch et push grâce à la transmission directe des données déjà prêtes depuis le disque. Par défaut, les index inverses ne sont pas créés, leur génération nécessite d'activer le paramètre «git config pack.writeReverseIndex true» suivi de la compression du dépôt avec la commande «git repack -Ad».
Des optimisations de performance ont été ajoutées, basées sur l'apparition du format de fichier commit-graph, utilisé pour optimiser l'accès aux informations sur les commits, ainsi que de nouvelles données sur le numéro de génération du commit, qui peuvent être utilisées pour accélérer des opérations supplémentaires sur les commits.
Les capacités de redéfinition du nom de la branche principale, utilisée par défaut dans les nouveaux dépôts (paramètre init.defaultBranch), ont été complétées. Lorsqu'il accède à des dépôts externes, git essaie d'extraire la branche pointée par HEAD, c'est-à-dire que si l'extérieur serveur utilise par défaut la branche «main», alors l'opération «git clone» tentera d'extraire localement «main». Dans Git 2.31, le support pour une telle extraction est désormais également réalisé pour les dépôts vides. Par exemple, lors du clonage local d'un nouveau dépôt avant d'y ajouter les premiers patchs, la copie locale contiendra maintenant le nom de la branche principale par défaut. le serveur
L'option «—disk-usage» a été ajoutée à la commande «git rev-list», permettant d'afficher des données récapitulatives sur la taille des objets.
Dans l'attente du remplacement imminent du backend pour l'exécution des fusions, la détection des renommages a été considérablement optimisée.
Le support de la bibliothèque de regex PCRE1 obsolète a été interrompu.
Il est désormais possible d'interdire de manière forcée l'utilisation de liens raccourcis, indépendamment de l'algorithme de hachage. L'interdiction est activée en attribuant la valeur « no » au paramètre core.abbrev.
La commande « git rev-parse » a été enrichie d'une option « —path-format=(absolute|relative) » pour définir explicitement le format de sortie des chemins relatifs ou absolus.
Dans les scripts d'autocomplétion pour Bash, l'ajout de règles d'autocomplétion pour ses propres sous-commandes « git » a été simplifié.
La commande « git bundle » a reçu une nouvelle option « —stdin » pour lire les références depuis l'entrée standard.
La commande « git log » a été dotée d'une nouvelle option « —diff-merges= ».
La commande « git ls-files » a été enrichie d'une option « —deduplicatecan » pour supprimer les doublons lors de l'affichage.
De nouveaux masques pour exclure une plage de commits ont été ajoutés : « ^! » et « ^- ».
La commande « git range-diff » a été dotée des options « —left-only » et « —right-only » pour afficher seulement un côté de la plage comparée.
Les commandes « git diff » et « git log » ont été dotées des options « —skip-to= » et « —rotate-to= » pour sauter ou déplacer à la fin des chemins de départ.
La commande « git difftool » a reçu une option « —skip-to= » pour reprendre une session interrompue à partir d'un chemin donné.
Le code de conduite (Code-of-conduct), définissant les principes fondamentaux de résolution des conflits entre développeurs, a été mis à jour vers la version 2.0 (l'ancienne version 1.4 était utilisée).

Source : opennet.ru