Après deux mois de développement, la version 2.35 du système distribué de gestion de code source Git a été publiée. Git est l'un des systèmes de gestion de version les plus populaires, fiables et performants, offrant des outils flexibles pour le développement non linéaire basés sur des branches et des fusions. Pour garantir l'intégrité de l'historique et la résistance aux changements rétroactifs, il utilise un hachage implicite de l'ensemble de l'historique précédent dans chaque commit, et il est également possible de certifier des tags et des commits par des signatures numériques des développeurs.
Comparé à la version précédente, 494 modifications ont été intégrées dans cette nouvelle version, préparées avec la participation de 93 développeurs, dont 35 ont participé pour la première fois au développement. Les principales nouveautés :
- Les capacités d'utilisation des clés SSH pour certifier les objets Git par signature numérique ont été étendues. Pour délimiter la validité de plusieurs clés, le support des directives OpenSSH « valid-before » et « valid-after » a été ajouté, permettant de garantir le bon fonctionnement des signatures après la rotation d'une clé par l'un des développeurs. Auparavant, il y avait un problème de séparation des signatures faites avec l'ancienne et la nouvelle clé : si l'ancienne clé était supprimée, il devenait impossible de vérifier les signatures effectuées avec celle-ci, et si elle était conservée, cela permettait de créer de nouvelles signatures avec l'ancienne clé, alors qu'une nouvelle clé avait déjà été mise en place. Avec les directives valid-before et valid-after, il est possible de délimiter le champ d'application des clés en fonction du moment de la création de la signature.
- Dans la configuration merge.conflictStyle, permettant de choisir le mode de présentation des informations sur les conflits lors de la fusion, le mode « zdiff3 » a été ajouté, déplaçant toutes les lignes standard mentionnées au début ou à la fin du conflit en dehors de la zone de conflit, ce qui permet d'obtenir une présentation plus compacte des informations.
- La commande «git stash» a été dotée d'un mode «—staged» qui permet de cacher uniquement les modifications ajoutées à l'index. Cela est particulièrement utile lorsqu'il faut temporairement mettre de côté une partie de changements complexes pour d'abord ajouter ce qui est prêt, et gérer le reste plus tard. Ce mode est similaire à la commande «git commit» qui enregistre uniquement les modifications présentes dans l'index, mais au lieu de créer un nouveau commit, «git stash —staged» stocke le résultat dans une zone temporaire de stash. Une fois les changements nécessaires, ils peuvent être récupérés avec la commande «git stash pop».
- La commande «git log» a reçu un nouveau spécificateur de format «—format=%(describe)», permettant de combiner la sortie de «git log» avec le résultat de l'exécution de la commande «git describe». Les paramètres pour «git describe» sont spécifiés directement dans le spécificateur («—format=%(describe:match=<foo>,exclude=<bar>)»), où il est également possible d'inclure des tags abrégés («—format=%(describe:tags=<bool>)») et de configurer le nombre de caractères hexadécimaux pour l'identification des objets («—format=%(describe:abbrev=<n>)»). Par exemple, pour afficher les 8 derniers commits, dont les tags ne portent pas la mention de candidat à la version, tout en affichant des identifiants de 8 caractères, on peut utiliser la commande : $ git log -8 —format='%(describe:exclude=*-rc*,abbrev=13)' v2.34.1-646-gaf4e5f569bc89 v2.34.1-644-g0330edb239c24 v2.33.1-641-g15f002812f858 v2.34.1-643-g2b95d94b056ab v2.34.1-642-gb56bd95bbc8f7 v2.34.1-203-gffb9f2980902d v2.34.1-640-gdf3c41adeb212 v2.34.1-639-g36b65715a4132
- La configuration user.signingKey prend en charge de nouveaux types de clés, ne se limitant pas au type «ssh-» et à la spécification du chemin complet du fichier clé. Les types alternatifs sont spécifiés par le préfixe «key::», par exemple, «key::ecdsa-sha2-nistp256» pour les clés ECDSA.
- La vitesse de génération de la liste des modifications en mode «—histogram» a été nettement améliorée, tout comme l'utilisation de l'option «—color-moved-ws», qui gère la mise en surbrillance des espaces dans le diff coloré.
- La commande «git jump», utilisée pour fournir à Vim des informations sur les transitions exactes vers une position recherchée dans le fichier lors de la résolution de conflits de fusion, de la visualisation des différences ou de l'exécution d'opérations de recherche, a été dotée de la possibilité de restreindre les conflits de fusion concernés. Par exemple, pour limiter les opérations uniquement au répertoire «foo», on peut spécifier «git jump merge — foo», tandis que pour exclure le répertoire «Documentation», on peut utiliser «git jump merge — ‘:^Documentation'».
- Des travaux ont été réalisés pour standardiser l'utilisation du type « size_t » au lieu de « unsigned long » pour les valeurs représentant la taille des objets, ce qui a permis d'appliquer les filtres « clean » et « smudge » avec des fichiers de plus de 4 Go sur toutes les plateformes, y compris celles utilisant le modèle de données LLP64, où le type « unsigned long » est limité à 4 octets.
- La commande « git am » a été enrichie d'une option « —empty=(stop|drop|keep) », permettant, lors de l'analyse des patches depuis la boîte de réception, de choisir le comportement pour les courriels vides ne contenant pas de patches. La valeur « stop » mettra fin à l'ensemble de l'opération d'application des patches, « drop » ignorera le patch vide, et « keep » créera un commit vide.
- Les commandes « git reset », « git diff », « git blame », « git fetch », « git pull » et « git ls-files » ont ajouté le support des index partiels (sparse index), permettant d'améliorer la performance et d'économiser de l'espace dans les dépôts où des opérations de clonage partiel (sparse-checkout) sont effectuées.
- La commande « git sparse-checkout init » a été déclarée obsolète et doit être remplacée par « git sparse-checkout set ».
- Une implémentation initiale du nouveau backend « reftable » a été ajoutée pour stocker des références, telles que des branches et des tags, dans le dépôt. Ce nouveau backend utilise un stockage par blocs appliqué par le projet JGit et est optimisé pour stocker un très grand nombre de références. Le backend n'est pas encore intégré au système de références (refs) et n'est pas prêt pour une utilisation pratique.
- La palette de couleurs de la commande « git grep » a été mise en conformité avec l'outil GNU grep.
Source : opennet.ru
