La version 2.54 du système de contrôle de version distribué Git a été publiée. Git se distingue par sa haute performance et fournit des outils de développement non linéaire, basés sur la ramification et la fusion de branches. Pour garantir l'intégrité de l'historique et la résistance aux modifications « rétroactives », Git utilise un hachage implicite de toute l'histoire précédente dans chaque commit, ainsi que la vérification par des signatures numériques des développeurs pour des tags et commits individuels. Le code Git est distribué sous la licence GPLv2+.
Comparée à la version précédente, la nouvelle version comprend 770 modifications, préparées avec la participation de 137 développeurs (66 d'entre eux ont participé au développement de Git pour la première fois). Les principales nouveautés :
- La commande « git history » a été mise en œuvre, offrant des fonctionnalités expérimentales pour réécrire l'historique des modifications, plus simples et plus sûres à utiliser que la rebase des commits avec la commande « git rebase ». Deux opérations sont fournies :
- « git history reword » pour réécrire le message dans le commit spécifié sans modifier l'arborescence de travail et l'index (sauf pour la note, le reste reste inchangé). Par exemple, pour corriger une faute de frappe.
- « git history split » pour séparer de manière interactive le commit spécifié en deux commits différents en déplaçant des parties sélectionnées du commit d'origine vers un commit supplémentaire.
Dans les futures versions, l'ajout de nouvelles commandes est prévu : « git history fixup » pour corriger un commit, « git history drop » pour supprimer un commit, « git history reorder » pour modifier l'ordre des commits et « git history squash » pour fusionner des commits.
- Une nouvelle méthode pour définir des gestionnaires (hooks) dans les fichiers de configuration a été mise en œuvre. Au lieu de placer des scripts avec des gestionnaires dans le répertoire «.git/hooks» de chaque dépôt, les commandes pour appeler les gestionnaires peuvent désormais être spécifiées directement dans les fichiers de configuration. Les paramètres peuvent être liés au dépôt ou spécifiés dans des fichiers de configuration s'appliquant à tous les dépôts (/etc/gitconfig) ou aux dépôts utilisateurs (~/.gitconfig). Il est possible de lier plusieurs gestionnaires à un seul événement. Les scripts dans «.git/hooks» continuent d'être appelés, mais s'exécutent après les gestionnaires des fichiers de configuration. Pour afficher la liste des gestionnaires, utilisez la commande «git hook list», et pour désactiver sélectivement l'appel de gestionnaires, utilisez le paramètre «hook..enabled = false». [hook «linter»] event = pre-commit command = ~/bin/linter —cpp20 [hook «no-leaks»] event = pre-commit command = ~/bin/leak-detector $ git hook list pre-commit global linter ~/bin/linter —cpp20 local no-leaks ~/bin/leak-detector
- Dans la commande «git maintenance», la stratégie par défaut est «geometric» («git config set maintenance.strategy geometric»), ce qui permet de réduire le temps de maintenance des grands monorépertoires. Par rapport à la stratégie précédemment appliquée, utilisant une logique similaire à la commande «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 (lorsque cela est possible, la fusion s'effectue par parties et sans nettoyage des objets supprimés).
- La base de données des objets (ODB) et les API associées ont été converties vers une nouvelle architecture, basée sur l'utilisation de backends plug-in. La restructuration réalisée abstrait le format de stockage des objets et permettra ultérieurement de mettre en œuvre des fonctionnalités telles que des backends alternatifs et des formats d'objets, par exemple, pour un stockage plus efficace de gros fichiers binaires ou pour optimiser le fonctionnement des grands hébergeurs git.
- La commande «git repo structure», qui affiche des informations sur la structure du dépôt, permet de visualiser non seulement la taille totale, mais aussi les plus gros objets de chaque type, ce qui permet d'évaluer la taille sans utiliser l'outil tiers git-sizer. $ git repo structure … | * Plus gros objets | | | * Commits | | | * Taille maximum [1] | 17,23 Ko | | * Parents maximum [2] | 10 | | * Arbres | | | * Taille maximum [3] | 58,85 Ko | | * Entrées maximum [4] | 1,18 k | | * Blobs | | | * Taille maximum [5] | 1019,51 Ko | | * Tags | | | * Taille maximum [6] | 7,13 Ko |
- La commande «git replay», utilisée au lieu de «git rebase» pour recréer l'historique sur le serveur sans arbre de travail, inclut par défaut la mise à jour atomique des références (au lieu d'afficher la liste des commandes update-ref pour une exécution manuelle), implémente l'option «—revert» pour annuler les modifications d'une série de commits, permet d'ignorer les commits vides résultants et introduit la possibilité de recréer l'historique jusqu'au commit racine.
- Dans «git rev-list» et des commandes similaires, l'option «—maximal-only» a été ajoutée pour montrer uniquement les commits inaccessibles par d'autres commits.
- L'option «—keys» a été ajoutée à la commande «git repo info» pour afficher la liste de toutes les clés connues.
- Dans la commande «git add -p», lors de la navigation entre les blocs de code à l'aide des touches «J» et «K», un marquage des blocs déjà approuvés et omis a été introduit. Une option «—no-auto-advance» a été ajoutée pour désactiver le passage automatique au fichier suivant, permettant de revenir aux fichiers précédents avant le commit.
- L'interface web «gitweb» a été optimisée pour fonctionner sur des appareils mobiles.
- Dans la commande «git apply —directory», une normalisation des chemins de fichiers, tels que «.\/un\/..\/normalized\/path», est assurée avant utilisation.
- La possibilité d'ajouter des sous-commandes personnalisées en plaçant des fichiers «git-» dans le répertoire des fichiers exécutables a été documentée.
- La commande «git send-email» a ajouté la prise en charge des certificats clients.
- Pour la commande «git status», une configuration «status.compareBranches» a été mise en place, permettant de spécifier les branches avec lesquelles la branche actuelle sera comparée. [status] compareBranches = @{upstream} @{push}
- Dans «git rebase», l'option «—trailer» a été ajoutée pour simplifier l'ajout de métadonnées à tous les commits. git rebase —trailer «Reviewed-by: Test »
- La commande « git fast-import » a été mise à jour avec la possibilité de remplacer les signatures pour les commits qui sont devenus invalides après l'importation.
- Ajout du support de la compression des index multi-pack (MIDX), permettant de regrouper de petits couches d'index MIDX contenant des informations sur la disponibilité des objets avec leurs fichiers bitmap associés, ce qui réduit le nombre de couches accumulées dans les dépôts anciens.
- La commande « git backfill » permet désormais de spécifier des révisions (plages de commits) et des masques de chemins (pathspec) pour limiter les parties de l'historique des modifications à charger. git backfill main~100..main git backfill — '*.c'
- Des formes alternatives d'appel pour la commande « git config list » ont été ajoutées : « git config -l » et « git config —list ».
- L'utilisation de caractères non-ASCII dans les noms d'alias de commandes définis dans le fichier de configuration est désormais autorisée. [alias « obtenir »] command = fetch
- L'affichage des signatures dont la validité des clés GPG a expiré, mais qui étaient valides au moment de la signature du commit, a été modifié. De telles signatures sont désormais affichées comme correctes avec une note sur l'expiration de la clé (auparavant, elles étaient surlignées en rouge, ce qui donnait une impression d'invalidité).
- L'accès aux dépôts via HTTP gère désormais l'erreur avec le code 429 (Trop de Requêtes). Les requêtes ayant échoué avec cette erreur sont désormais considérées comme un problème temporaire, pour lequel une nouvelle tentative doit être effectuée après un certain temps. Le retard avant la répétition est défini par l'option « http.retryAfter », le nombre de répétitions par « http.maxRetries », et le temps d'attente par « http.maxRetryTime ».
Source : opennet.ru
