Après deux mois de développement, le système de contrôle de code source distribué Git 2.39 est sorti. Git est l'un des systèmes de contrôle de versions les plus populaires, les plus fiables et les plus performants, fournissant des outils de développement non linéaires flexibles 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 tout l'historique précédent est utilisé dans chaque commit ; il est également possible de certifier des balises et des commits individuels avec les signatures numériques des développeurs.
Par rapport à la version précédente, la nouvelle version comprenait 483 modifications préparées avec la participation de 86 développeurs, dont 31 ont participé au développement pour la première fois. Principales innovations :
- La commande « git shortlog », destinée à afficher des résumés avec des statistiques de l'historique des modifications, a ajouté une option « -group » pour le regroupement arbitraire des commits par champs non limités à l'auteur ou au committer. Par exemple, pour afficher une liste de développeurs avec des informations sur le nombre de modifications, en tenant compte des assistants mentionnés dans le champ "Co-authored-by", vous pouvez utiliser la commande : git shortlog -ns --group=author - -group=trailer:co-écrit par
La sortie du Shortlog peut être agrégée à l'aide de spécificateurs de formatage, et l'option « --group » peut considérablement simplifier la création de rapports complexes et éliminer le besoin de commandes de tri supplémentaires. Par exemple, pour créer un rapport contenant des informations sur le nombre de commits acceptés pour une version donnée chaque mois, vous pouvez spécifier : git shortlog v2.38.0.. —date='format:%Y-%m' —group=' %cd' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Auparavant, pour effectuer une opération similaire il aurait fallu utiliser les utilitaires sort et uniq : git log v2.38.0 .. —date='format:%Y -%m' —format='%cd' | trier | uniq -c
- Les capacités du mécanisme « cruft packs », conçu pour compresser des objets inaccessibles et non référencés dans le référentiel (non référencés par des branches ou des balises), ont été étendues. Les objets inaccessibles sont supprimés par le garbage collector, mais restent dans le référentiel pendant un certain temps avant d'être supprimés pour éviter les conditions de concurrence. Le mécanisme « cruft packs » vous permet de stocker tous les objets inaccessibles dans un seul fichier pack, et d'afficher les données sur l'heure de modification de chaque objet dans un tableau séparé, stocké dans un fichier séparé avec l'extension « .mtimes », afin qu'ils le fassent. ne chevauche pas la durée totale de modification.
La durée pendant laquelle les objets inaccessibles restent dans le référentiel avant d'être réellement supprimés est déterminée par l'option « -prune= » " Cependant, bien que retarder la suppression soit un moyen assez efficace et pratique d'empêcher la corruption du référentiel due à des conditions de concurrence critique, il n'est pas fiable à 100 %. Pour faciliter la restauration d'un référentiel endommagé, la nouvelle version offre la possibilité de sauvegarder les objets manquants en ajoutant l'option « --expire-to » à la commande « git repack », qui permet de spécifier un fichier pour créer un référentiel externe. copie de tous les objets supprimés. Par exemple, pour enregistrer les objets inaccessibles qui n'ont pas changé au cours des 5 dernières minutes dans le fichier backup.git, vous pouvez utiliser la commande : git repack --cruft --cruft-expiration=5.minutes.ago -d --expire -to=../backup.git
- Augmentation significative (jusqu'à 70 %) de la vitesse de l'opération "git grep -cached" lors de la recherche dans des zones qui utilisent le clonage partiel (sparse-checkout) et pour lesquelles il existe des index partiels (sparse index). Auparavant, lors de la spécification de l'option « -cached », la recherche était effectuée d'abord dans l'index régulier, puis dans les index partiels, ce qui entraînait des retards notables lors de la recherche dans les grands référentiels.
- La vérification par le serveur de la cohérence des nouveaux objets avant leur placement dans le dépôt lors de l'opération « git push » a été accélérée. En passant à la comptabilisation des seuls liens déclarés lors de la vérification, dans un référentiel de test comportant 7 millions de liens, dont seulement 3 % sont couverts par l'opération push, les optimisations introduites ont permis de réduire le temps de vérification de 4.5 fois.
- Pour se protéger contre d'éventuels dépassements d'entier dans le code, la commande "git apply" limite la taille maximale des correctifs pouvant être traités. Si la taille du patch dépasse 1 Go, une erreur s'affichera désormais.
- Pour se protéger contre les vulnérabilités potentielles, des modifications ont été apportées pour nettoyer les informations inutiles des en-têtes définis lors de l'utilisation du module h2h3 avec l'option GIT_TRACE_CURL=1 ou GIT_CURL_VERBOSE=1 avec HTTP/2.
- Lors d'une extraction sur une branche qui est un lien symbolique vers une autre branche, la commande "git symbolic-ref HEAD" affiche désormais le nom de la branche cible plutôt que le nom du lien symbolique.
- Ajout de la prise en charge de l'argument @{-1} à l'option « --edit-description » (« git branch —edit-description @{-1} ») pour modifier la description d'une branche précédente.
- Ajout de la commande "git merge-tree --stdin" pour transmettre une liste de paramètres via l'entrée standard.
- Sur les systèmes de fichiers réseau, le gestionnaire fsmonitor, qui surveille les modifications apportées au système de fichiers, est désactivé par défaut.
Source: opennet.ru