Git, le système distribué de gestion de versions, vient de passer à la version 2.28

Et remplace le nom master par init.defaultBranch lors de la création d'une première branche dans un référentiel

Git, le système distribué de gestion de versions vient de passer à la version 2.28. Voici un aperçu de certaines des fonctionnalités et des modifications les plus intéressantes apportées.

Présentation de init.defaultBranch

Lorsque vous initialisez un nouveau référentiel Git à partir de zéro avec git init, Git a toujours créé une première branche initiale avec le nom master. Dans Git 2.28, une nouvelle option de configuration, init.defaultBranch est introduite pour remplacer le terme codé en dur. Ce changement a été annoncé par la Software Freedom Conservancy qui s'inscrit dans un mouvement plus général dans l'industrie informatique pour supprimer les expressions qui pourraient avoir des connotations négatives :

« Conservancy et le projet Git sont conscients que le nom initial de la branche, "master", est offensant pour certaines personnes et nous compatissons avec ceux qui sont blessés par l’utilisation de ce terme.

« Les versions existantes de Git sont capables de fonctionner avec n'importe quel nom de branche; il n’y a rien de spécial à propos de ‘master’ sauf qu’il a toujours été le nom utilisé pour la première branche lors de la création d’un nouveau dépôt à partir de zéro (avec la commande git init). Ainsi, de nombreux projets l'utilisent pour représenter la ligne principale de développement. Nous soutenons et encourageons les projets à passer à des noms de branche significatifs et inclusifs, et nous ajouterons des fonctionnalités à Git pour rendre encore plus facile l'utilisation d'une valeur par défaut différente pour les nouveaux projets.

« Dans un premier temps, Git ajoutera un mécanisme pour permettre aux utilisateurs de spécifier la valeur par défaut utilisée comme nom de la première branche lors de la création d'un nouveau référentiel. De plus, conformément à sa gouvernance de projet, Git a entrepris un processus communautaire pour explorer le changement du nom de la première branche créée automatiquement pour les nouveaux référentiels en dehors de «master». Ce changement est actuellement discuté sur notre liste de diffusion. Comme toujours, les modifications apportées au cœur de Git minimiseront les perturbations pour les utilisateurs de Git et incluront des périodes de dépréciation appropriées.

« Pendant ce temps, Git en tant que projet reste engagé dans l'encouragement de la participation des groupes sous-représentés au développement de Git lui-même. Git poursuit sa participation, commencée il y a quatre ans, à l'initiative Outreachy de Conservancy. Conservancy continue également d'explorer et de soutenir d'autres initiatives qui peuvent également aider dans ce domaine. »

C'est dans ce contexte qu'a été proposé init.defaultBranch qui sera désormais recherché par git init à la place de master lors de la création de la première branche dans un nouveau référentiel. Cependant, si cette valeur n'est pas définie, init.defaultBranch va utiliser par défaut master.


Filtres de Bloom de chemin modifié

Un filtre de Bloom est une structure de données. C'est une implémentation du type abstrait Ensemble. Cette structure est probabiliste, c'est-à-dire qu'elle utilise des probabilités, et que sa correction est probabiliste. Plus précisément, lors du test de la présence d'un élément dans un ensemble, un filtre de Bloom permet de savoir :

• avec certitude que l'élément est absent de l'ensemble (il ne peut pas y avoir de faux négatif) ;
• avec une certaine probabilité que l'élément peut être présent dans l'ensemble (il peut y avoir des faux positifs).

Dans Git 2.27, le format de fichier de commit-graph a été étendu pour stocker les filtres de Bloom de chemin modifié. Cela signifie dans un sens que ces nouvelles informations aident Git à trouver les points de l'historique qui ont touché un chemin donné beaucoup plus rapidement (par exemple, git log -- <path> ou git blame). Git 2.28 tire parti de ces optimisations pour offrir une poignée d'améliorations de performances importantes.

Dans les termes les plus simples, le fichier de commit-graph stocke des informations sur les commits. Essentiellement, le commit-graph agit comme un cache pour les informations couramment utilisées sur les commits : qui sont leurs parents, quel est leur arbre racine, ainsi de suite. Il stocke également des informations calculées, comme le numéro de génération d'un commit et des filtres de Bloom de chemin modifié.

Pourquoi stocker toutes ces informations ? Avant d'y répondre, il est utile d'avoir une compréhension rapide de la façon dont Git stocke les objets. Git stocke les objets de deux manières: soit en tant qu'objet libre (auquel cas le contenu de l'objet est stocké dans un seul fichier unique à cet objet sur le disque), soit en tant qu'objet compressé (auquel cas l'objet est assemblé à partir d'un format compressé dans un fichier *.pack). Quelle que soit la manière dont un commit est stocké, Git doit toujours l'analyser et le décompresser avant que ses champs tels que root tree et parents ne soient accessibles.

Avec un fichier de commit-graph, toutes ces informations sont immédiates : pour un commit C donné, Git sait exactement où chercher dans un fichier de commit-graph pour tous ces champs que Git stocke et peut les lire immédiatement, pas de décompression ou d'assemblage requis. Cela peut réduire le temps de vos opérations Git habituelles en soi, mais le commit-graph brille vraiment dans les données calculées qu'il stocke.

Les numéros de génération sont une sorte d'index d'accessibilité qui peut aider Git à répondre très rapidement à des questions telles que l'accessibilité et l'ordre topologique.

Quelques autres nouvelles fonctionnalités

• Git inclut désormais un workflow GitHub Actions que vous pouvez utiliser pour exécuter les propres tests d'intégration de Git sur une variété de plates-formes et de compilateurs. Aucun effort supplémentaire n'est requis de votre part: si vous avez un fork de git / git sur GitHub, chaque push sera exécuté à travers le tableau de tests nécessaires pour valider votre changement. Si vous pouvez utiliser une liste de diffusion sur Git, avec cette version vous pourrez désormais vous servir de GitGitGadget sur le référentiel git / git. Cela signifie que vous pouvez ouvrir une pull request et demander à GitGitGadget de l'envoyer à la liste de diffusion en votre nom. Donc, si vous êtes plus à l'aise pour contribuer à Git comme ça au lieu de composer des e-mails manuellement, vous pouvez désormais contribuer à Git du début à la fin en utilisant GitHub.
• D'un autre côté, si cela ne vous dérange pas d'envoyer un e-mail ou deux, il est désormais beaucoup plus facile d'interagir avec la liste de diffusion Git lorsque vous rencontrez un bogue en exécutant git bugreport. L'exécution de cette nouvelle commande ouvrira votre $EDITOR avec un formulaire prérempli de questions qui seront utiles pour déboguer votre problème. Il comprend également des informations utiles sur votre système, comme l'architecture de votre processeur, la version de Git que vous utilisez, etc. Lorsque vous avez terminé, vous pouvez envoyer ce fichier sous forme de corps d'un e-mail à la liste de diffusion Git.
• git status a également appris de nouvelles astuces. Désormais, git status peut vous rappeler quand vous êtes dans un sparse checkout en vous indiquant le pourcentage de fichiers que vous avez extraits.Pour ceux qui aiment utiliser git-prompt.sh, l'invite affichera désormais SPARSE si vous êtes dans un sparse checkout.

Source : GitHub, Software Freedom Conservancy