Sortie du système de gestion de versions Git 2.39

Après deux mois de développement, la version 2.39 du système de gestion de versions distribuée Git a été publiée. 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 le branching et le merging. Pour maintenir l'intégrité de l'historique et la résistance aux modifications rétroactives, l'hachage implicite de tout l'historique antérieur est utilisé dans chaque commit, et il est également possible de certifier numériquement les signatures des développeurs pour certains tags et commits.

Comparé à la version précédente, cette nouvelle version intègre 483 modifications, préparées par la participation de 86 développeurs, dont 31 ont participé au développement pour la première fois. Les principales nouveautés :

• La commande « git shortlog », conçue pour afficher des résumés avec des statistiques de l'historique des modifications, a été dotée de l'option « —group » pour le groupement arbitraire des commits par des champs ne se limitant pas à l'auteur ou au committer. Par exemple, pour afficher la liste des développeurs avec des informations sur le nombre de modifications, en tenant compte des co-auteurs mentionnés dans le champ « Co-authored-by », vous pouvez utiliser la commande : git shortlog -ns —group=author —group=trailer:co-authored-by

  La sortie de shortlog peut être agrégée à l'aide de spécificateurs de formatage, et l'option « —group » permet de simplifier considérablement la création de rapports complexes et d'éviter l'exécution de commandes supplémentaires de tri. Par exemple, pour créer un rapport indiquant combien de commits pour une version donnée ont été acceptés chaque mois, on peut spécifier : git shortlog v2.38.0.. —date='format:%Y-%m' —group='' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Auparavant, pour effectuer une opération similaire, il aurait fallu utiliser les utilitaires sort et uniq : git log v2.38.0.. —date='format:%Y-%m' —format='' | sort | uniq -c
• Les capacités du mécanisme «cruft packs», destiné à empaqueter les objets inaccessibles, pour lesquels il n'existe pas de lien dans le dépôt (ni de branches ni de tags), ont été étendues. Les objets inaccessibles sont supprimés par le ramasse-miettes, mais restent dans le dépôt pendant un certain temps avant leur suppression afin d'éviter des conditions de course. Le mécanisme «cruft packs» permet de stocker tous les objets inaccessibles dans un seul fichier pack, avec les données sur la date de modification de chaque objet reflétées dans une table séparée, enregistrée dans un fichier distinct ayant l'extension «.mtimes», afin qu'elles ne se chevauchent pas avec le temps de modification global.

  La durée de conservation des objets inaccessibles dans le dépôt avant leur suppression effective est définie par l'option «—prune=». Bien que le délai avant la suppression soit un moyen assez efficace et pratique d'éviter la corruption du dépôt en raison des conditions de course, il n'est pas 100 % fiable. Pour simplifier la récupération d'un dépôt corrompu, une fonction de sauvegarde des objets manquants a été ajoutée dans la nouvelle version, permettant de conserver une copie externe de tous les objets supprimés ; pour cela, une option «—expire-to» a été ajoutée à la commande «git repack». Par exemple, pour sauvegarder dans le fichier backup.git les objets inaccessibles qui n'ont pas été modifiés au cours des 5 dernières minutes, vous pouvez utiliser la commande : git repack —cruft —cruft-expiration=5.minutes.ago -d —expire-to=../backup.git

• La vitesse d'exécution de l'opération «git grep —cached» a été considérablement augmentée (jusqu'à 70 %) lors de la recherche dans les zones où le clonage partiel (sparse-checkout) est utilisé et pour lesquelles des index partiels (sparse index) existent. Auparavant, lorsque l'option «—cached» était spécifiée, la recherche se faisait d'abord dans l'index normal, puis dans les index partiels, ce qui entraînait des retards significatifs lors de la recherche dans de grands dépôts.
• L'exécution a été accélérée sur le serveur la vérification de la cohérence des nouveaux objets avant leur insertion dans le dépôt lors de l'opération «git push». Grâce au passage à la prise en compte uniquement des références déclarées lors de la vérification, dans un dépôt de test contenant 7 millions de références, dont seulement 3 % sont concernées par l'opération push, les optimisations apportées ont permis de réduire le temps de vérification par 4,5 fois.
• Pour se protéger contre de potentielles vulnérabilités d'entier dans le code, la commande « git apply » limite la taille maximale des correctifs traités. Si la taille du correctif dépasse 1 Go, une erreur sera désormais affichée.
• Pour se prémunir contre d'éventuelles vulnérabilités, des modifications ont été apportées pour nettoyer les informations superflues dans les en-têtes lors de l'utilisation du module h2h3 avec les options GIT_TRACE_CURL=1 ou GIT_CURL_VERBOSE=1 en lien avec HTTP/2.
• Lors de l'exécution de l'opération checkout sur une branche qui est un lien symbolique vers une autre branche, la commande « git symbolic-ref HEAD » affichera désormais le nom de la branche cible au lieu du nom du lien symbolique.
• Ajout du support de l'argument @{-1} dans l'option « --edit-description » (« git branch --edit-description @{-1} ») pour modifier la description de la branche précédente.
• Ajout de la commande « git merge-tree --stdin », permettant de transmettre une liste de paramètres via le flux d'entrée standard.
• Sur les systèmes de fichiers en réseau, le gestionnaire fsmonitor, qui suit les modifications du système de fichiers, est désactivé par défaut.

Source : opennet.ru