Sortie de la version 2.26 du système de contrôle de version distribué Git

Disponible lancement d'un système de gestion décentralisé des textes sources Git 2.26.0. Git est l'un des systèmes de gestion de versions les plus populaires, fiables et performants, offrant des outils flexibles de développement non linéaire basés sur le branchement et la fusion. Pour garantir l'intégrité de l'historique et la résistance aux modifications rétroactives, un hachage implicite de l'ensemble de l'historique précédent est utilisé dans chaque commit, et il est également possible de vérifer numériquement par des signatures des développeurs pour des tags et commits spécifiques.

Comparé à la version précédente, la nouvelle version comprend 504 modifications, préparées avec la participation de 64 développeurs, dont 12 ont participé au développement pour la première fois. Principales nouveautés:

• La transition par défaut vers la deuxième version du protocole de communication Git, qui est utilisé lors de la connexion distante d'un client au serveur Git. La deuxième version du protocole se distingue par la possibilité de filtrer les branches et les tags côté serveur, en fournissant au client une liste réduite de références. Auparavant, lors de l'exécution de toute commande de récupération, une liste complète de références dans tout le dépôt était toujours envoyée au client, même lorsque le client ne mettait à jour qu'une seule branche ou vérifiait la validité de sa copie du dépôt. Une autre nouveauté marquante est la capacité d'ajouter de nouvelles fonctionnalités au protocole aux mesures de l'apparition de nouvelles fonctionnalités dans les outils. Le code client reste compatible avec l'ancien protocole et peut continuer à fonctionner à la fois avec de nouveaux et d'anciens serveurs, revenant automatiquement à la première version si le serveur ne prend pas en charge la seconde.
• La commande « git config » a été dotée de l'option « --show-scope » qui facilite l'identification de l'endroit où certaines configurations sont définies. Git permet de définir des paramètres à différents endroits : dans le dépôt (.git/info/config), dans le répertoire de l'utilisateur (~/.gitconfig), dans le fichier de configuration système (/etc/gitconfig), ainsi que via les options de ligne de commande et les variables d'environnement. Lors de l'exécution de « git config », il est souvent difficile de comprendre où la configuration recherchée est définie. Pour résoudre ce problème, l'option « --show-origin » était disponible, mais elle ne montre que le chemin vers le fichier où la configuration est définie, ce qui est utile si l'on souhaite modifier le fichier, mais ne permet pas de changer la valeur via « git config » en utilisant les options « --system », « --global » ou « --local ». La nouvelle option « --show-scope » affiche le contexte de définition des variables et peut être utilisée avec « --show-origin » :

  $ git --list --show-scope --show-origin
  global file:/home/user/.gitconfig diff.interhunkcontext=1
  global file:/home/user/.gitconfig push.default=current
  […]
  local file:.git/config branch.master.remote=origin
  local file:.git/config branch.master.merge=refs/heads/master

  $ git config --show-scope --get-regexp 'diff.*'
  global diff.statgraphwidth 35
  local diff.colormoved plain

  $ git config --global --unset diff.statgraphwidth

• Dans les paramètres de liaison des informations d'identification l'utilisation de masques dans l'URL est autorisée. Toutes les configurations HTTP et les informations d'identification dans Git peuvent être définies pour toutes les connexions (http.extraHeader, credential.helper) ainsi que pour les connexions liées à une URL (credential.https://example.com.helper, credential.https://example.com.helper). Jusqu'à présent, l'utilisation de masques, tels que *.example.com, n'était autorisée que pour les configurations HTTP, mais n'était pas prise en charge pour la liaison des informations d'identification. Dans Git 2.26, ces différences ont été supprimées et, par exemple, pour lier un nom d'utilisateur à tous les sous-domaines, il est désormais possible d'indiquer :

  [credential "https://*.example.com"]

  username = ttaylorr

• La prise en charge expérimentale du clonage partiel (partial clones) continue de s'élargir, permettant de ne transférer qu'une partie des données et de travailler avec une copie incomplète du dépôt. Dans cette nouvelle version, une nouvelle commande « git sparse-checkout add » a été ajoutée, permettant d'ajouter des répertoires individuels pour appliquer l'opération « checkout » uniquement à une partie de l'arborescence de travail, au lieu de lister tous ces répertoires à la fois par la commande « git sparse-checkout set » (il est possible d'ajouter un répertoire à la fois, sans avoir à redéfinir toute la liste à chaque fois).
  Par exemple, pour cloner le dépôt git/git sans transmettre les blobs, en limitant la vérification uniquement au répertoire racine de la copie de travail et avec un marquage distinct pour l'extraction des répertoires «t» et «Documentation», vous pouvez spécifier :

  $ git clone —filter=blob:none —sparse git@github.com:git/git.git

  $ cd git
  $ git sparse-checkout init —cone

  $ git sparse-checkout add t
  ….
  $ git sparse-checkout add Documentation
  ….
  $ git sparse-checkout list
  Documentation
  t

• Les performances de la commande «git grep», utilisée pour rechercher dans le contenu actif du dépôt ainsi que dans les révisions historiques, ont été considérablement améliorées. Pour accélérer la recherche, il était possible de scanner le contenu de l'arborescence de travail en utilisant plusieurs threads («git grep —threads»), mais les recherches dans les révisions historiques étaient effectuées en un seul fil. Maintenant, cette limitation a été levée grâce à l'implémentation de la possibilité de paralléliser les opérations de lecture depuis le stockage d'objets. Par défaut, le nombre de threads est fixé au nombre de cœurs CPU, ce qui dans la plupart des cas ne nécessite plus un réglage explicite de l'option «—threads».
• Ajout de la prise en charge de l'autocomplétion pour les sous-commandes, chemins, références et autres arguments de la commande «git worktree», permettant de travailler avec plusieurs copies de travail du dépôt.
• Ajout de la prise en charge des couleurs vives, pour lesquelles il existe des séquences d'échappement ANSI. Par exemple, dans les paramètres de couleurs de syntaxe «git config —color» ou «git diff —color-moved» à travers l'option «—format», pour un bleu vif, vous pouvez spécifier «%C(brightblue)».
• Ajout d'une nouvelle version du script fsmonitor-watchman, assurant l'intégration avec le mécanisme Facebook Watchman pour accélérer le suivi des modifications de fichiers et l'apparition de nouveaux fichiers. Après la mise à jour de git, il est nécessaire de remplacer le hook dans le dépôt.
• Ajout d'optimisations pour accélérer les opérations de clonage partiel (partial clones), liées à l'utilisation de bitmaps
  (bitmap machinery) pour éviter un examen complet de tous les objets pendant le filtrage des résultats. La vérification des blobs (—filter=blob:none et —filter=blob:limit=n) lors du clonage partiel est maintenant effectuée
  de manière nettement plus rapide. GitHub a annoncé l'application de patchs avec ces optimisations et une prise en charge expérimentale du clonage partiel.
• La commande « git rebase » a été migrée vers un autre backend, utilisant par défaut le mécanisme ‘merge’ (précédemment utilisé pour « rebase -i ») au lieu de ‘patch+apply’. Dans certains détails, les backends diffèrent, par exemple, après la reprise de l'opération après la résolution d'un conflit (git rebase —continue), le nouveau backend propose d'éditer le message du commit, tandis que l'ancien se contentait d'utiliser l'ancien message. Pour revenir à l'ancien comportement, vous pouvez utiliser l'option « —apply » ou définir la variable de configuration ‘rebase.backend’ sur ‘apply’.
• Un exemple de gestionnaire de paramètres d'authentification, défini via .netrc, a été adapté pour un usage immédiat.
• Ajout de la configuration gpg.minTrustLevel pour définir le niveau minimum de confiance pour divers éléments exécutant la vérification de signature numérique.
• Ajout de l'option « —pathspec-from-file » dans « git rm » et « git stash ».
• Le développement des suites de tests se poursuit dans le cadre de la préparation à la transition vers l'algorithme de hachage SHA-2 au lieu de SHA-1.

Source : opennet.ru