Le système de gestion des textes sources Git 2.41 est disponible.

Après trois mois de développement, la version 2.41 du système de gestion décentralisé des fichiers source 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 ramification et la fusion de branches. Pour garantir l'intégrité de l'historique et la résistance aux modifications rétroactives, un hachage implicite de toute l'histoire précédente est effectué dans chaque commit. Il est également possible de valider numériquement certains tags et commits par des signatures de développeurs.

Comparée à la version précédente, cette nouvelle version intègre 542 modifications, préparées par 95 développeurs, dont 29 ont participé au développement pour la première fois. Les principales nouveautés :

• Le traitement des objets inaccessibles (unreachable), qui ne sont pas référencés dans le dépôt (pas de référence par des branches ou des tags), a été amélioré. Les objets inaccessibles sont supprimés par le collecteur de déchets, mais restent dans le dépôt un certain temps avant la suppression pour éviter les états de concurrence. Pour suivre la période de présence des objets inaccessibles, il est nécessaire de leur attribuer des étiquettes avec le temps de modification de ces objets, ce qui empêche leur stockage dans un même fichier pack où tous les objets partagent le même temps de modification. Auparavant, chaque objet inaccessible était sauvegardé dans un fichier séparé, ce qui posed des problèmes lorsqu'il y avait un grand nombre d'objets inaccessibles récents, qui n’étaient pas encore sujets à la suppression. Dans cette nouvelle version, un mécanisme de « cruft packs » est par défaut utilisé pour empaqueter les objets inaccessibles, permettant de stocker tous les objets inaccessibles dans un seul fichier pack, tandis que les données sur le temps de modification de chaque objet sont reflétées dans une table séparée, stockée dans un fichier avec l'extension « .mtimes » et reliée à l'aide d'un fichier d'index avec l'extension « .idx ».
• La tenue d'un indice inverse sur disque (revindex) pour les fichiers pack est activée par défaut. Lors de tests sur le dépôt torvalds/linux, l'utilisation de l'indice inverse a permis d'accélérer les opérations gourmandes en ressources « git push » de 1,49 fois, et les opérations simples, comme le calcul de la taille d'un objet à l'aide de « git cat-file —batch='%(objectsize:disk)' », de 77 fois. Les fichiers (« .rev ») avec l'indice inverse seront enregistrés à l'intérieur du dépôt dans le répertoire « .git/objects/pack ».

  Rappelons que Git stocke toutes les données sous forme d'objets, qui sont placés dans des fichiers séparés. Pour améliorer l'efficacité du travail avec le dépôt, les objets sont également regroupés dans des fichiers pack, où les informations sont présentées sous la forme d'un flux d'objets se suivant (un format similaire est utilisé lors de la transmission d'objets avec les commandes git fetch et git push). Pour chaque fichier pack, un fichier d'index (.idx) est créé, permettant de déterminer très rapidement, par l'identifiant de l'objet, le décalage dans le fichier pack où cet objet est stocké.

  L'index inversé inclus dans la nouvelle version vise à optimiser le processus de détermination de l'identifiant de l'objet à partir des informations sur le placement de l'objet dans le fichier pack. Auparavant, cette conversion était effectuée à la volée lors de l'analyse du fichier pack et n'était stockée qu'en mémoire, ce qui empêchait la réutilisation de ces index et obligeait à générer l'index à chaque fois. L'opération de construction de l'index consiste à créer un tableau de paires « objet-position » et à le trier par position, ce qui peut prendre beaucoup de temps pour de gros fichiers pack.

  Par exemple, l'opération d'affichage du contenu des objets, utilisant un index direct, s'exécutait 62 fois plus vite que l'opération affichant la taille des objets, pour laquelle les données de liaison de position à objet n'étaient pas indexées. Après utilisation de l'index inversé, les opérations mentionnées ont pris un temps à peu près égal. Les index inversés permettent également d'accélérer les opérations d'envoi d'objets lors des commandes fetch et push grâce à la transmission directe des données déjà préparées depuis le disque.

  
• Le protocole « credential helper », utilisé pour transmettre des informations d'identification lors de l'accès à des dépôts à accès limité, a été enrichi d'une prise en charge du passage des en-têtes WWW-Authenticate entre le gestionnaire d'informations d'identification et le service où l'authentification a lieu. La prise en charge de l'en-tête WWW-Authenticate permet de transmettre des paramètres de portée OAuth pour un partage d'accès utilisateur plus granulaire aux dépôts et pour délimiter les domaines accessibles aux requêtes.
• La commande for-each-ref a été ajoutée avec l'option de formatage «%(ahead-behind:<base>)», permettant d'obtenir en une fois des informations sur le nombre de commits présents ou absents dans une branche donnée par rapport à une autre branche (à quel point une branche est en retard ou en avance sur l'autre au niveau des commits). Auparavant, pour obtenir de telles informations, il fallait exécuter deux commandes distinctes : «git rev-list —count main..my-feature» pour le nombre de commits uniques à la branche et «git rev-list —count my-feature..main» pour le nombre de commits absents. Maintenant, ces calculs peuvent être réduits à une seule commande, ce qui simplifie l'écriture des gestionnaires et réduit le temps d'exécution. Par exemple, pour afficher les branches qui n'ont pas été fusionnées et évaluer leur retard ou avance par rapport à leur branche principale, on peut utiliser une commande en ligne : $ git for-each-ref —no-merged=origin/HEAD \ —format='%(refname:short) %(ahead-behind:origin/HEAD)' \ refs/heads/tb/ | column -t tb/cruft-extra-tips 2 96 tb/for-each-ref—exclude 16 96 tb/roaring-bitmaps 47 3 au lieu du script précédemment utilisé, qui s'exécutait 17 fois plus lentement : $ git for-each-ref —format='%(refname:short)' —no-merged=origin/HEAD \ refs/heads/tb | while read ref do ahead="$(git rev-list —count origin/HEAD..$ref)" behind="$(git rev-list —count $ref..origin/HEAD)" printf "%s %d %d\n" "%$ref" "%$ahead" "%$behind" done | column -t tb/cruft-extra-tips 2 96 tb/for-each-ref—exclude 16 96 tb/roaring-bitmaps 47 3
• La commande «git fetch» a été ajoutée avec l'option «—porcelain», qui, lorsqu'elle est spécifiée, génère une sortie au format «<flag> <old-object-id> <new-object-id> <local-reference>», moins lisible mais plus pratique pour l'analyse dans les scripts.
• Une nouvelle configuration «fetch.hideRefs» a été ajoutée, ce qui permet d'accélérer les opérations «git fetch» en cachant une partie des références dans le dépôt local lors de la vérification par le serveur de l'ensemble complet des objets, ce qui permet d'économiser du temps en limitant la vérification uniquement aux serveurs, à partir desquelles les données sont extraites directement. Par exemple, lors d'un test sur un système avec des dépôts contenant un grand nombre de liens externes suivis, exclure toutes les références sauf celles destinées au serveur $remote a permis de réduire le temps d'exécution de l'opération «git fetch» de 20 minutes à 30 secondes. $ git -c fetch.hideRefs=refs -c fetch.hideRefs=!refs/remotes/$remote \ fetch $remote
• La commande «git fsck» a introduit la possibilité de vérifier les corruptions, la correspondance des sommes de contrôle et la validité des valeurs dans les cartes de disponibilité et les index inversés.
• Dans l'équipe « git clone —local », une sortie d'erreur a été mise en œuvre lors de la tentative de copie à partir d'un dépôt contenant des liens symboliques à l'intérieur de $GIT_DIR.

Source : opennet.ru