Git 2.34 est disponible avec une fonction d'indexation compatible avec les fichiers épars

Et des améliorations en matière de performances

L'équipe Git a annoncé lundi Git 2.34. La nouvelle mouture de Git contient des fonctionnalités et des corrections de bogues provenant de plus de 109 contributeurs, dont 29 sont de nouveaux contributeurs. La nouveauté principale ajoute une fonction de prise en charge de l'index clairsemé pour aider à gérer les très grands dépôts Git. Ce format d'index est capable de comprendre les contenus marqués et d'indiquer la relation entre les contenus lors de l'extraction clairsemée. Voici ci-dessous les points forts de Git 3.34.

Introduction d'un index clairsemé

Selon l'équipe Git, sparse-checkout, particulièrement conçu pour les monorepos étendus, est un bon moyen pour extraire et éditer seulement une partie du dépôt. 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 spécification de filtre définie avec le paramètre --filter ne reprend également qu'une partie de l'original. Elle a ajouté que jusqu'à présent, 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 à sparse-checkout ou qui sont à la limite entre celui-ci et le dépôt complet. 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. Pour rappel, dans les systèmes de contrôle de version, un monorepo est une stratégie de développement logiciel où le code de nombreux projets est stocké dans le même référentiel.

Une nouvelle stratégie de fusion par défaut

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 utilise par défaut la stratégie ort au lieu de récursive lors de la fusion. Le nom de la nouvelle stratégie est un acronyme pour Ostensibly Recursive's Twin, le jumeau apparent de la stratégie récursive. L'implémentation complètement réécrite de la stratégie de fusion repose sur les mêmes concepts de base que la récursive, mais est censée éviter de nombreux problèmes de performance de l'approche récursive tout en améliorant la correction.

Contrairement à la récursive, ort ne travaille pas sur l'index. La communauté a probablement corrigé certains bogues connus de l'ancienne stratégie lors de la réécriture. En outre, l'ancienne approche ne pouvait être étendue et optimisée que de manière fastidieuse en raison de son histoire. À l'origine, elle était basée sur un script Python qui utilisait les commandes de plomberie de Git. Selon un billet de blogue 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.

Selon l'équipe, dans des cas extrêmes avec une série de fusions similaires, par exemple dans le cas d'un rebase, 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.

Accessibilité, SSH et fautes de frappe

Une autre nouveauté concerne les bitmaps d'accessibilité, dans lesquels Git enregistre la manière dont les différents objets de chaque commit sont accessibles. Jusqu'à présent, les fichiers .bitmap étaient limités à des packfiles individuels, car ils étaient liés à la disposition des objets dans un packfile. L'équipe a annoncé que Git 2.34 introduit un nouveau format bitmap qui apporte un index multi-pack (MIDX) pour le travail avec plusieurs packfiles. Il convient également de mentionner que les développeurs peuvent désormais utiliser des clefs SSH au lieu des signatures PGP pour signer.

Enfin, il y a une nouvelle option pour help.autoCorrect, qui détermine la manière dont la gestion des versions traite les erreurs de frappe comme git psuh. En plus des variantes précédentes never pour aucune correction et un nombre de secondes ou immediate pour corriger automatiquement, Git 2.34 connaît depuis peu l'option prompt qui demande de manière interactive si Git doit réexécuter une commande qui a échoué avec la correction proposée.

Source : Git 2.34

Et vous ?

Que pensez-vous des nouveautés de Git 2.34 ?

Voir aussi

Git : les développeurs utilisent-ils le système de contrôle de version de façon optimale ? Il semblerait que beaucoup de développeurs se limitent au strict minimum

Tout comprendre sur le projet Skara : abandon de Mercurial pour Git, un tutoriel de Lilian Benoit

La version 3.0 de Magit, une interface Git dans Emacs, est disponible, elle contient 1264 commits provenant de 87 contributeurs

Git 2.26.0 est disponible avec le protocole de transport v2 par défaut et une mise à jour de la sous-commande git sparse-checkout