Git 2.22 (Q2 2019) introduit trace2avec commit ee4512e par Jeff Hostetler :
trace2: créer une nouvelle fonction de trace combinée
Créez une nouvelle fonction de traçage unifié pour git.
L'intention éventuelle est de remplacer les routines actuelles trace_printf*et trace_performance*par un ensemble unifié de git_trace2*routines.
En plus de l'API de style printf habituelle, trace2fournit des verbes d'événements de plus haut niveau avec des champs fixes permettant d'écrire des données structurées.
Cela facilite le post-traitement et l'analyse des outils externes.
Trace2 définit 3 cibles de sortie.
Celles-ci sont définies à l'aide des variables d'environnement " GIT_TR2", " GIT_TR2_PERF" et " GIT_TR2_EVENT".
Ceux-ci peuvent être définis sur "1" ou sur un chemin absolu (tout comme l'actuel GIT_TRACE).
Remarque: concernant le nom de la variable d'environnement, utilisez toujours GIT_TRACExxx, non GIT_TRxxx.
Donc en fait GIT_TRACE2, GIT_TRACE2_PERFou GIT_TRACE2_EVENT.
Voir le changement de nom Git 2.22 mentionné plus loin ci-dessous.
Ce qui suit est le travail initial sur cette nouvelle fonctionnalité de traçage, avec les anciens noms de variables d'environnement:
GIT_TR2est destiné à remplacer GIT_TRACEet consigne les données récapitulatives de la commande.
GIT_TR2_PERFest destiné à remplacer GIT_TRACE_PERFORMANCE.
Il étend la sortie avec des colonnes pour le processus de commande, le thread, le dépôt, les temps écoulés absolus et relatifs. Il signale des événements pour le démarrage / l'arrêt du processus enfant, le démarrage / l'arrêt de thread et l'imbrication de fonction par thread.
GIT_TR2_EVENTest un nouveau format structuré. Il écrit les données d'événement sous la forme d'une série d'enregistrements JSON.
Les appels vers les fonctions de Trace2 connecter à l' un des 3 cibles de sortie permis sans qu'il soit nécessaire d'appeler différentes trace_printf*ou trace_performance*routines.
Voir commit a4d3a28 (21 mars 2019) par Josh Steadmon ( steadmon) .
(Fusionné par Junio C Hamano - gitster- dans commit 1b40314 , 08 mai 2019)
trace2: écrire dans les cibles du répertoire
Lorsque la valeur d'une variable d'environnement trace2 est un chemin absolu faisant référence à un répertoire existant, écrivez la sortie dans les fichiers (un par processus) sous le répertoire donné.
Les fichiers seront nommés en fonction du dernier composant du SID trace2, suivi d'un compteur pour éviter les collisions potentielles.
Cela rend plus pratique la collecte de traces pour chaque appel git en définissant sans condition la trace2variable envvar appropriée sur un nom de répertoire constant.
Voir aussi commit f672dee (29 avril 2019) et commit 81567ca , commit 08881b9 , commit bad229a , commit 26c6f25 , commit bce9db6 , commit 800a7f9 , commit a7bc01e , commit 39f4317 , commit a089724 , commit 1703751 (15 avril 2019) par Jeff Hostetler ( jeffhostetler) .
(Fusionné par Junio C Hamano - gitster- dans commit 5b2d1c0 , 13 mai 2019)
La nouvelle documentation comprend désormais des paramètres de configuration qui ne sont lus qu'à partir du système et des fichiers de configuration globaux (ce qui signifie que les fichiers de configuration locaux et d'arbre de travail du référentiel et les -carguments de ligne de commande ne sont pas respectés.)
Exemple :
$ git config --global trace2.normalTarget ~/log.normal
$ git version
git version 2.20.1.155.g426c96fcdb
rendements
$ cat ~/log.normal
12:28:42.620009 common-main.c:38 version 2.20.1.155.g426c96fcdb
12:28:42.620989 common-main.c:39 start git version
12:28:42.621101 git.c:432 cmd_name version (version)
12:28:42.621215 git.c:662 exit elapsed:0.001227 code:0
12:28:42.621250 trace2/tr2_tgt_normal.c:124 atexit elapsed:0.001265 code:0
Et pour la mesure de la performance :
$ git config --global trace2.perfTarget ~/log.perf
$ git version
git version 2.20.1.155.g426c96fcdb
rendements
$ cat ~/log.perf
12:28:42.620675 common-main.c:38 | d0 | main | version | | | | | 2.20.1.155.g426c96fcdb
12:28:42.621001 common-main.c:39 | d0 | main | start | | 0.001173 | | | git version
12:28:42.621111 git.c:432 | d0 | main | cmd_name | | | | | version (version)
12:28:42.621225 git.c:662 | d0 | main | exit | | 0.001227 | | | code:0
12:28:42.621259 trace2/tr2_tgt_perf.c:211 | d0 | main | atexit | | 0.001265 | | | code:0
Comme documenté dans Git 2.23 (Q3 2019), la variable d'environnement à utiliser est GIT_TRACE2.
Voir commit 6114a40 (26 juin 2019) par Carlo Marcelo Arenas Belón ( carenas) .
Voir commit 3efa1c6 (12 juin 2019) par Ævar Arnfjörð Bjarmason ( avar) .
(Fusionné par Junio C Hamano - gitster- in commit e9eaaa4 , 09 juil.2019 )
Cela fait suite au travail effectué dans Git 2.22: commit 4e0d3aa , commit e4b75d6 (19 mai 2019) par SZEDER Gábor ( szeder) .
(Fusionné par Junio C Hamano - gitster- dans commit 463dca6 , 30 mai 2019)
trace2: renommer les variables d'environnement en GIT_TRACE2 *
Pour une variable d'environnement censée être définie par les utilisateurs, le GIT_TR2* sont tout simplement trop floues, incohérentes et laides.
La plupart des établis GIT_*variables d'environnement ne pas utiliser les abréviations, et dans le cas des rares qui le font ( GIT_DIR, GIT_COMMON_DIR, GIT_DIFF_OPTS) il est tout à fait évident que les abréviations ( DIRet OPTS) représentent.
Mais qu'est-ce que cela signifie TR? Suivi, traditionnel, remorque, transaction, transfert, transformation, transition, traduction, transplantation, transport, traversée, arborescence, déclencheur, tronquer, faire confiance, ou ...?!
La fonction trace2, comme l'indique le suffixe «2» dans son nom, est censée finir par remplacer la fonction de trace originale de Git.
Il est raisonnable de s'attendre à ce que les variables d'environnement correspondantes suivent le mouvement, et après les GIT_TRACEvariables d' origine , elles sont appelées GIT_TRACE2; il n'y a rien de tel ' GIT_TR'.
Toutes les variables de configuration spécifiques à trace2 sont, très sensiblement, dans la trace2section «», pas dans « tr2».
OTOH, on ne gagne rien du tout en omettant les trois derniers caractères de "trace" dans les noms de ces variables d'environnement .
Renommons donc toutes GIT_TR2*les variables d'environnement en GIT_TRACE2*, avant qu'elles ne se retrouvent dans une version stable.
Git 2.24 (Q3 2019) améliore l'initialisation du référentiel Git.
Voir commit 22932d9 , commit 5732f2b , commit 58ebccb (06 août 2019) par Jeff King ( peff) .
(Fusionné par Junio C Hamano - gitster- dans commit b4a1eec , 09 sept. 2019)
common-main: retarder l'initialisation de trace2
Nous initialisons le trace2système dans la fonction commune main () afin que tous les programmes (même ceux qui ne sont pas intégrés) permettent le traçage.
Mais le trace2démarrage est relativement lourd, car nous devons réellement lire la configuration sur disque pour décider s'il faut tracer.
Cela peut provoquer des interactions inattendues avec d'autres initialisations communes principales. Par exemple, nous finirons dans le code de configuration avant d'appeler initialize_the_repository(), et l'invariant habituel qui the_repositoryn'est jamais NULL ne tiendra pas.
Poussons l' trace2initialisation plus bas dans common-main, juste avant l'exécution cmd_main().
Git 2.24 (Q4 2019) garantit également que la sortie du trace2sous-système est formatée plus joliment maintenant.
Voir commit 742ed63 , commit e344305 , commit c2b890a (09 août 2019), commit ad43e37 , commit 04f10d3 , commit da4589c (08 août 2019) et commit 371df1b (31 juillet 2019) par Jeff Hostetler ( jeffhostetler) .
(Fusionné par Junio C Hamano - gitster- dans commit 93fc876 , 30 sept. 2019)
Et, toujours Git 2.24
Voir commit 87db61a , commit 83e57b0 (4 octobre 2019) et commit 2254101 , commit 3d4548e (3 octobre 2019) par Josh Steadmon ( steadmon) .
(Fusionné par Junio C Hamano - gitster- dans commit d0ce4d9 , 15 octobre 2019)
trace2: ignorer les nouvelles traces si le répertoire cible contient trop de fichiers
Signé par: Josh Steadmon
trace2peut écrire des fichiers dans un répertoire cible.
Avec une utilisation intensive, ce répertoire peut se remplir de fichiers, ce qui pose des problèmes pour les systèmes de traitement de trace.
Ce patch ajoute une option de configuration ( trace2.maxFiles) pour définir un nombre maximum de fichiers qui trace2seront écrits dans un répertoire cible.
Le comportement suivant est activé lorsque le maxFilesest défini sur un entier positif:
L'hypothèse est qu'un système de traitement des traces distinct traite les traces générées; une fois qu'il a traité et supprimé le fichier sentinel, il devrait être sûr de générer à nouveau de nouveaux fichiers de trace.
La valeur par défaut de trace2.maxFilesest zéro, ce qui désactive la vérification du nombre de fichiers.
La configuration peut également être remplacé par une nouvelle variable d'environnement: GIT_TRACE2_MAX_FILES.
Et Git 2.24 (Q4 2019) enseigne à trace2 les git pushétapes.
Voir commit 25e4b80 , commit 5fc3118 (02 octobre 2019) par Josh Steadmon ( steadmon) .
(Fusionné par Junio C Hamano - gitster- dans commit 3b9ec27 , 15 octobre 2019)
push: ajouter une instrumentation trace2
Signé par: Josh Steadmon
Ajoutez des régions trace2 dans transport.cet builtin/push.cpour mieux suivre le temps passé dans les différentes phases de poussée:
- Liste des références
- Vérification des sous-modules
- Pousser des sous-modules
- Pousser les refs
Avec Git 2.25 (Q1 2020), une partie des fichiers Documentation/technicalest déplacée vers les *.hfichiers d'en- tête .
Voir commit 6c51cb5 , commit d95a77d , commit bbcfa30 , commit f1ecbe0 , commit 4c4066d , commit 7db0305 , commit f3b9055 , commit 971b1f2 , engager 13aa9c8 , engager c0be43f , engager 19ef3dd , engager 301d595 , engager 3a1b341 , engager 126c1cc , engager d27eb35 , engager 405c6b1 , commit d3d7172 , validez 3f1480b , commit 266f03e , validation 13c4d7e(17 novembre 2019) parHeba Waly ( HebaWaly) .
(Fusionné par Junio C Hamano - gitster- in commit 26c816a , 16 déc 2019)
trace2: déplacer le document vers trace2.h
Signé par: Heba Waly
Déplacez la documentation des fonctions de Documentation/technical/api-trace2.txtvers trace2.hcar il est plus facile pour les développeurs de trouver les informations d'utilisation à côté du code au lieu de les rechercher dans un autre fichier doc.
Seule la section de documentation des fonctions est supprimée Documentation/technical/api-trace2.txtcar le fichier est plein de détails qui semblaient plus appropriés pour être dans un fichier doc séparé tel quel, avec un lien vers le fichier doc ajouté dans trace2.h. De plus, les fonctions doc sont supprimées pour éviter d'avoir des informations redondantes qui seront difficiles à synchroniser avec la documentation dans le fichier d'en-tête.
(bien que cette réorganisation ait eu un effet secondaire sur une autre commande, expliqué et corrigé avec Git 2.25.2 (mars 2020) dans commit cc4f2eb (14 février 2020) par Jeff King ( peff) .
(fusionné par Junio C Hamano - gitster- dans commit 1235384 , 17 févr.2020 ) )
Avec Git 2.27 (Q2 2020): amélioration de Trace2 pour permettre la journalisation des variables d'environnement .
Voir commit 3d3adaa (20 mars 2020) par Josh Steadmon (steadmon ) .
(Fusionné par Junio C Hamano - gitster- dans commit 810dc64 , 22 avril 2020)
trace2: apprendre à Git à consigner les variables d'environnement
Signé par: Josh Steadmon
Reconnu par: Jeff Hostetler
Via trace2, Git peut déjà enregistrer des paramètres de configuration intéressants (voir le trace2_cmd_list_config() fonction). Cependant, cela peut donner une image incomplète car de nombreux paramètres de configuration permettent également des remplacements via des variables d'environnement.
Pour permettre des journaux plus complets, nous ajoutons une nouvelle trace2_cmd_list_env_vars()fonction et une implémentation de prise en charge, inspirée de l'implémentation de journalisation des paramètres de configuration préexistante.
Avec Git 2.27 (T2 2020), apprenez aux codepaths qui affichent la barre de progression à utiliser également les start_progress()et les stop_progress()appels comme "region " à tracer.
Voir commit 98a1364 (12 mai 2020) par Emily Shaffer ( nasamuffin) .
(Fusionné par Junio C Hamano - gitster- dans commit d98abce , 14 mai 2020)
trace2: temps de progression du journal et débit
Signé par: Emily Shaffer
Plutôt que d'enseigner une seule opération, comme 'git fetch comment écrire le débit dans les traces, nous pouvons en apprendre davantage sur un large éventail d'opérations utilisateur qui peuvent sembler lentes en ajoutant des outils à la bibliothèque de progression elle-même .
Les opérations qui affichent la progression sont susceptibles d'être lentes et le genre de chose dont nous voulons de toute façon surveiller les performances.
En montrant le nombre d'objets et la taille du transfert de données, nous devrions être en mesure de faire des mesures dérivées pour nous assurer que les opérations sont mises à l'échelle comme nous le prévoyons.
Et:
Avec Git 2.27 (Q2 2020), correctif de dernière minute pour notre récent changement pour permettre l'utilisation de l'API progress comme une région traçable.
Voir commit 3af029c (15 mai 2020) par Derrick Stolee ( derrickstolee) .
(Fusionné par Junio C Hamano - gitster- dans commit 85d6e28 , 20 mai 2020)
progress: appeler trace2_region_leave()seulement après avoir appelé_enter()
Signé par: Derrick Stolee
Un utilisateur de l'API progress appelle start_progress()conditionnellement et dépend des fonctions display_progress()et stop_progress()pour devenir no-op lorsqu'il start_progress()n'a pas été appelé.
Comme nous l' avons ajouté un appel à trace2_region_enter()la start_progress(), les appels vers d' autres appels de l' API trace2 des fonctions API de progrès doivent faire en sorte que ces appels sont Trace2 lorsque sautéestart_progress() n'ont pas été appelés sur la structure de progression.
Plus précisément, n'appelez pas à trace2_region_leave()partir du stop_progress()moment où nous n'avons pas appelé start_progress(), ce qui aurait appelé la correspondance trace2_region_enter().
GIT_CURL_VERBOSE, vous aurez avec Git 2.9.x / 2.10GIT_TRACE_CURL. Voir ma réponse ci-dessous .