AccueilActualités informatiqueGestion des versions : Git 2.34 épure l'index

Gestion des versions : Git 2.34 épure l’index

La version 2.34 du logiciel de gestion de versions Git a été publiée. Cette version s’accompagne d’une nouvelle architecture d’index qui est censée apporter des avantages en termes de performances en interaction avec les extractions éparses et le clonage partiel. En outre, la nouvelle stratégie de fusion, qui était déjà préparée dans le prédécesseur, est maintenant disponible. ort est à bord, et les bitmaps d’accessibilité ne sont plus nécessairement liés à un seul fichier d’emballage.

Sommaire

Surtout pour les monorepos étendus, un sparse-checkout est un bon moyen de vérifier et d’éditer seulement une partie du référentiel. Les répertoires individuels peuvent être modifiés au lieu de l’ensemble du contenu. Le clonage partiel d’un référentiel via une commande spécifiée avec le paramètre --filter ne reprend qu’une partie de l’original.

Auparavant, dans les deux cas, le sous-ensemble respectif était encore fortement lié à l’ensemble du référentiel, puisque l’index se réfère à l’ensemble de sa portée. Git 2.34 introduit maintenant un index « sparse-enabled » qui contient seulement les parties du dépôt partiel qui appartiennent au « sparse checkout » ou qui sont à la limite entre celui-ci et le dépôt complet. Il existe un article de blog détaillé sur GitHub concernant les détails techniques de l’index à base de données éparses.

L’index clairsemé de droite ne gère que les arbres (triangles) et les blobs (carrés) nécessaires au travail partiel de l’index complet de gauche.

(Image : GitHub)

Cela élimine l’ancienne surcharge de l’index complet qui devait suivre chaque changement dans l’ensemble du référentiel, même s’il n’avait pas de connexion directe avec le clone partiel ou l’extraction éparse.

La deuxième innovation majeure était déjà annoncée dans la version 2.33, sortie en août : à partir de la version actuelle, Git s’appuie par défaut sur la stratégie de ort au lieu de recursive. Le nom de la nouvelle stratégie est un acronyme pour Ostensibly recursives Twin, c’est-à-dire le jumeau apparent de la stratégie récursive.

L’implémentation entièrement réécrite de la stratégie de fusion repose sur les mêmes concepts de base que ceux utilisés dans la stratégie de fusion. recursivemais vise à éviter de nombreux problèmes de performance de l’approche récursive tout en améliorant la correction. Contrairement à recursive ort pas sur l’index. En outre, la communauté a probablement corrigé certains bogues connus de l’ancienne stratégie pendant la réécriture. En raison de son histoire, l’ancienne approche n’a pu être étendue et optimisée qu’avec difficulté. À l’origine, il était basé sur un script Python qui utilisait les commandes de plomberie de Git.

Selon un billet de blog sur Git 2.34, la nouvelle approche montre sa force surtout lorsque la fusion est associée à de nombreux changements de nom. L’article parle d’un gain de performance allant jusqu’à un facteur 500. Dans des cas extrêmes avec une série de fusions similaires, par exemple dans le cas d’un rebasement, le gain de performance peut probablement même dépasser un facteur 9000. En dehors des scénarios extrêmes, tous les développeurs devraient bénéficier d’une amélioration modérée des performances et, surtout, d’une diminution des erreurs lors des fusions en modifiant la stratégie standard.

Une autre nouvelle fonctionnalité concerne les bitmaps d’accessibilité, dans lesquels Git enregistre comment les objets individuels des commits respectifs peuvent être atteints. Auparavant, les fichiers .bitmap étaient limités aux packfiles individuels car ils étaient liés à la disposition des objets dans un packfile. Git 2.34 introduit un nouveau format de bitmap qui apporte un index multi-pack (MIDX) pour travailler avec plusieurs packfiles.

Il convient également de mentionner que les développeurs peuvent désormais utiliser des clés SSH au lieu de signatures PGP pour la signature. Enfin, il existe une nouvelle option pour help.autoCorrectqui détermine la manière dont la gestion des versions traite les fautes de frappe telles que git psuh est traitée. En plus des variantes précédentes never pour aucune correction et un certain nombre de secondes ou immediate pour la correction automatique, Git 2.34 connaît maintenant l’option promptqui demande interactivement si Git doit ré-exécuter une commande qui a échoué avec la correction suggérée.

La liste complète des modifications apportées à Git 2.34 se trouve dans les notes de publication. Une description détaillée des nouvelles fonctionnalités les plus importantes peut être trouvée dans un billet de blog sur GitHub.

Plus d'articles