🥇Git 2.54 | ProHoster

Présenté publication d'un système de gestion distribué de textes originaux Git 2.54. Git se caractérise par sa haute performance et fournit des outils de développement non linéaire basés sur la branchement et la fusion de branches. Pour garantir l'intégrité de l'historique et la résistance aux modifications « rétroactives », il utilise un hachage implicite de tout l'historique précédent dans chaque commit, ainsi que la certification par des signatures numériques des développeurs pour les tags et commits individuels. Code Git est distribué sous licence GPLv2+.

Comparé à la version précédente, la nouvelle version a apporté 770 modifications, préparées avec la participation de 137 développeurs (66 ont participé au développement de Git pour la première fois).

Principales nouveautés:

La commande «git history» a été mise en œuvre, offrant des capacités expérimentales pour réécrire l'historique des modifications, plus simples et plus sûres à utiliser que le rebase des commits avec la commande git rebase. Deux opérations sont fournies :
- git history reword pour réécrire le message dans le commit spécifié sans modifier l'arbre de travail et l'index (à l'exception de la note, le reste demeure intact). Par exemple, pour corriger une faute de frappe.
- git history split pour diviser de manière interactive le commit spécifié en deux commits différents en déplaçant des parties sélectionnées du commit d'origine vers un commit supplémentaire.
Dans les futures versions, l'ajout de commandes supplémentaires est prévu : git history fixup pour corriger un commit, git history drop pour supprimer un commit, git history reorder pour modifier l'ordre des commits et git history squash pour fusionner des commits.
Une nouvelle méthode de définition des gestionnaires (hook) dans les fichiers de configuration a été mise en œuvre. Au lieu de placer des scripts de gestionnaires dans le répertoire .git/hooks de chaque dépôt, les commandes pour appeler les gestionnaires peuvent désormais être spécifiées directement dans les fichiers de configuration. Les réglages peuvent être liés au dépôt ou spécifiés dans des fichiers de configuration applicables à tous les dépôts (/etc/gitconfig) ou aux dépôts de l'utilisateur (~/.gitconfig). Il est possible de lier plusieurs gestionnaires à un même événement. Les scripts dans .git/hooks continuent à être appelés, mais ils sont exécutés après les gestionnaires provenant des fichiers de configuration. Pour voir la liste des gestionnaires, il convient d'utiliser la commande git hook list, et pour désactiver sélectivement l'appel des gestionnaires, le réglage hook..enabled = false :

[hook "linter"] event = pre-commit command = ~\/bin\/linter —cpp20 [hook "no-leaks"] event = pre-commit command = ~\/bin\/leak-detector $ git hook list pre-commit global linter ~\/bin\/linter —cpp20 local no-leaks ~\/bin\/leak-detector

Dans l'équipe «git maintenance» la stratégie par défaut utilisée est géométrique (git config set maintenance.strategy geometric), ce qui permet de réduire le temps de maintenance des grands monorepo. Par rapport à la stratégie précédemment utilisée, qui reposait sur la logique de la commande git gc, la nouvelle stratégie évite de réemballer tous les objets et exclut les opérations trop gourmandes en ressources, comme la fusion de tous les fichiers pack (lorsque cela est possible, la fusion se fait par parties et sans nettoyage des objets supprimés).
La base de données des objets (ODB) et les API associées ont été révisées pour s'appuyer sur une nouvelle architecture utilisant des backends plugables. La restructuration effectuée abstrait le format de stockage des objets et permettra à terme d'implémenter des fonctionnalités telles que des backends alternatifs et des formats d'objets, par exemple pour un stockage plus efficace de gros fichiers binaires ou pour optimiser le fonctionnement de grands services d'hébergement git.
Dans l'équipe «structure du dépôt git», fournissant des informations sur la structure du dépôt, a été conçue pour afficher non seulement la taille totale, mais aussi pour montrer les plus gros objets de chaque type, ce qui permet d'évaluer la taille sans utiliser d'outil tiers. git-sizer.

Dans l'équipe «git replay», utilisé à la place de git rebase pour recréer l'historique sur le serveur sans l'arbre de travail, inclut par défaut une mise à jour atomique des références (au lieu d'afficher une liste de commandes update-ref à exécuter manuellement), implémente l'option —revert pour annuler les modifications d'une série de commits, élimine les commits vides résultants et permet la recréation de l'historique jusqu'au commit racine.
Dans «git rev-list» et des commandes similaires, une option —maximal-only a été ajoutée pour afficher uniquement les commits inaccessibles par d'autres commits.
Dans la commande «git repo info», une option —keys a été ajoutée pour afficher la liste de toutes les clés connues.
Dans l'équipe «git add -p» Lors de la navigation entre les blocs de code à l'aide des touches « J » et « K », les blocs déjà approuvés et ignorés sont marqués. Une option —no-auto-advance a été ajoutée pour désactiver le passage automatique au fichier suivant, permettant de revenir à des fichiers antérieurs avant le commit.
Optimisation de l'interface web «gitweb» pour une utilisation sur des appareils mobiles.
Dans l'équipe «git apply –directory» avant utilisation, une normalisation des chemins de fichiers a été assurée, tels que .\/un\/..\/normalized\/path.
La possibilité d'ajouter des sous-commandes personnalisées en plaçant des fichiers git- dans le répertoire des fichiers exécutables a été documentée.
Dans la commande «git send-email» le support des certificats clients a été ajouté.
Pour la commande «git status», une configuration status.compareBranches a été mise en œuvre, permettant d’indiquer les branches avec lesquelles la branche actuelle sera comparée :

[status] compareBranches = @{upstream} @{push}

Dans «git rebase» une option —trailer a été ajoutée pour simplifier l'ajout de métadonnées à tous les commits :

git rebase —trailer "Reviewed-by: Test "`

Dans la commande «git fast-import» la possibilité de remplacer les signatures pour des commits devenus invalides après importation a été ajoutée.
Ajout du support de l'emballage (compaction) des indices multi-pack MIDX (multi-pack index), qui combine les petites couches de l'indice MIDX avec les informations de disponibilité des objets et les fichiers bitmap associés, permettant de réduire le nombre de couches accumulées dans des dépôts anciens.
Dans la commande git backfill, la possibilité d’indiquer des révisions (plages de commits) et des masques de chemins (pathspec) pour limiter les parties de l'historique des modifications à télécharger a été mise en œuvre :

git backfill main~100..main git backfill — ‘*.c’

Des formes alternatives pour appeler la commande git config list – git config -l et git config —list ont été ajoutées.
L'utilisation de caractères non-ASCII dans les noms des alias de commandes définis dans le fichier de configuration a été autorisée :

[alias "fetch"] command = fetch

L'affichage des signatures dont la validité des clés GPG a expiré, mais qui étaient valides au moment de la signature du commit, a été modifié. De telles signatures sont désormais affichées comme correctes avec une note sur l'expiration de la clé (auparavant, elles étaient surlignées en rouge, ce qui donnait une impression d'invalidité).
Lors de l'accès aux dépôts via HTTP, un traitement de l'erreur avec le code 429 (Trop de demandes) a été mis en place. Les requêtes qui se sont soldées par cette erreur sont désormais considérées non pas comme un problème fatal, mais comme une erreur temporaire, pour laquelle il convient de réessayer après un certain temps. Le délai avant la nouvelle tentative est défini via l'option http.retryAfter, le nombre de tentatives – http.maxRetries, et le temps d'attente – http.maxRetryTime.

Source : linux.org.ru