Comment puis-je avoir des informations de débogage concernant git / git-shell?

J'ai eu un problème, qui user1pouvait cloner un référentiel sans problème, alors que user2je ne pouvais en cloner qu'un vide. J'avais mis GIT_TRACE=1, mais rien d'utile n'a été dit.

Enfin, après de longs essais et erreurs, il s'est avéré qu'il s'agissait d'un problème d'autorisation sur un fichier. Un message d'erreur approprié pourrait court-circuiter ce problème.

Pour une sortie encore plus détaillée, utilisez ce qui suit:

GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull origin master

Débogage

Git a un ensemble assez complet de traces intégrées que vous pouvez utiliser pour déboguer vos problèmes git.

Pour les activer, vous pouvez définir les variables suivantes:

• GIT_TRACE pour les traces générales,
• GIT_TRACE_PACK_ACCESS pour le traçage de l'accès au packfile,
• GIT_TRACE_PACKET pour le traçage au niveau des paquets pour les opérations réseau,
• GIT_TRACE_PERFORMANCE pour la journalisation des données de performance,
• GIT_TRACE_SETUP pour obtenir des informations sur la découverte du référentiel et de l'environnement avec lequel il interagit,
• GIT_MERGE_VERBOSITY pour le débogage de la stratégie de fusion récursive (valeurs: 0-5),
• GIT_CURL_VERBOSEpour la journalisation de tous les messages curl (équivalent à curl -v),
• GIT_TRACE_SHALLOW pour le débogage, la récupération / le clonage de référentiels peu profonds.

Les valeurs possibles peuvent inclure:

• true, 1ou 2pour écrire à stderr,
• un chemin absolu commençant par /pour tracer la sortie vers le fichier spécifié.

Pour plus de détails, voir: Git Internals - Environment Variables

SSH

Pour les problèmes SSH, essayez les commandes suivantes:

echo 'ssh -vvv "$*"' > ssh && chmod +x ssh
GIT_SSH="$PWD/ssh" git pull origin master

ou utilisez sshpour valider vos informations d'identification, par exemple

ssh -vvvT [email protected]

ou via le port HTTPS:

ssh -vvvT -p 443 [email protected]

^{Remarque: réduisez le nombre de -vpour réduire le niveau de verbosité.}

Exemples

$ GIT_TRACE=1 git status
20:11:39.565701 git.c:350               trace: built-in: git 'status'

$ GIT_TRACE_PERFORMANCE=$PWD/gc.log git gc
Counting objects: 143760, done.
...
$ head gc.log 
20:12:37.214410 trace.c:420             performance: 0.090286000 s: git command: 'git' 'pack-refs' '--all' '--prune'
20:12:37.378101 trace.c:420             performance: 0.156971000 s: git command: 'git' 'reflog' 'expire' '--all'
...

$ GIT_TRACE_PACKET=true git pull origin master
20:16:53.062183 pkt-line.c:80           packet:        fetch< 93eb028c6b2f8b1d694d1173a4ddf32b48e371ce HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2:2.6.5~update-ref-initial-update-1494-g76b680d
...

essaye celui-là:

GIT_TRACE=1 git pull origin master

Si c'est via SSH, vous pouvez utiliser ce qui suit:

Pour un niveau de débogage plus élevé pour le type -vv ou -vvv pour les niveaux de débogage 2 et 3 respectivement:

# Debug level 1
GIT_SSH_COMMAND="ssh -v" git clone <repositoryurl>

# Debug level 2
GIT_SSH_COMMAND="ssh -vv" git clone <repositoryurl>

# Debug level 3
GIT_SSH_COMMAND="ssh -vvv" git clone <repositoryurl>

Ceci est principalement utile pour gérer les problèmes de clé publique et privée avec le serveur. Vous pouvez utiliser cette commande pour n'importe quelle commande git, pas seulement «git clone».

Git 2.9.x / 2.10 (Q3 2016) ajoute une autre option de débogage: GIT_TRACE_CURL .

Voir commit 73e57aa , commit 74c682d (23 mai 2016) par Elia Pinto ( devzero2000) .
Aidé par: Torsten Bögershausen ( tboegi) , Ramsay Jones, Junio ​​C Hamano ( gitster) , Eric Sunshine ( sunshineco) et Jeff King ( peff) .
^{(Fusionné par Junio ​​C Hamano - gitster- in commit 2f84df2 , 06 juil 2016)}

http.c: mettre en œuvre le GIT_TRACE_CURL variable d'environnement

Implémentez la GIT_TRACE_CURLvariable d'environnement pour permettre un plus grand degré de détail GIT_CURL_VERBOSE, en particulier l'en-tête de transport complet et toutes les données utiles échangées.
Cela peut être utile si une situation particulière nécessite une analyse de débogage plus approfondie.

La documentation indiquera:

GIT_TRACE_CURL

Active un vidage de trace complet curl de toutes les données entrantes et sortantes, y compris les informations descriptives, du protocole de transport git.
C'est similaire à fairecurl --trace-ascii sur la ligne de commande.

Cette option remplace la définition de la GIT_CURL_VERBOSEvariable d'environnement.

Vous pouvez voir cette nouvelle option utilisée dans cette réponse , mais aussi dans les tests Git 2.11 (T4 2016):

Voir commit 14e2411 , commit 81590bf , commit 4527aa1 , commit 4eee6c6 (07 septembre 2016) par Elia Pinto ( devzero2000) .
^{(Fusionné par Junio ​​C Hamano - gitster- in commit 930b67e , 12 sept 2016)}

Utilisez la nouvelle GIT_TRACE_CURLvariable d'environnement au lieu de la variable obsolète GIT_CURL_VERBOSE .

GIT_TRACE_CURL=true git clone --quiet $HTTPD_URL/smart/repo.git

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:

• Quand trace2écrirait un fichier dans un répertoire cible, vérifiez d'abord si les traces doivent être supprimées ou non. Les traces doivent être supprimées si:

  • il y a un fichier sentinelle déclarant qu'il y a trop de fichiers
  • OU, le nombre de fichiers dépasse trace2.maxFiles.
    Dans ce dernier cas, nous créons un fichier sentinelle nommé git-trace2-discardpour accélérer les contrôles futurs.

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().

Avez-vous essayé d'ajouter l' -vopérateur verbose ( ) lors du clonage?

git clone -v git://git.kernel.org/pub/scm/.../linux-2.6 my2.6

Pour les anciennes versions de git (1.8 et antérieures)

Je n'ai trouvé aucun moyen approprié d'activer le débogage SSH dans les anciennes versions de git et ssh. J'ai cherché des variables d'environnement en utilisantltrace -e getenv ... et trouvé aucune combinaison de variables GIT_TRACE ou SSH_DEBUG qui fonctionnerait.

Au lieu de cela, voici une recette pour injecter temporairement 'ssh -v' dans la séquence git-> ssh:

$ echo '/usr/bin/ssh -v ${@}' >/tmp/ssh
$ chmod +x /tmp/ssh
$ PATH=/tmp:${PATH} git clone ...
$ rm -f /tmp/ssh

Voici le résultat de la version 1.8.3 de git avec la version ssh OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 février 2013 clonant un dépôt github:

$ (echo '/usr/bin/ssh -v ${@}' >/tmp/ssh; chmod +x /tmp/ssh; PATH=/tmp:${PATH} \
   GIT_TRACE=1 git clone https://github.com/qneill/cliff.git; \
   rm -f /tmp/ssh) 2>&1 | tee log
trace: built-in: git 'clone' 'https://github.com/qneill/cliff.git'
trace: run_command: 'git-remote-https' 'origin' 'https://github.com/qneill/cliff.git'
Cloning into 'cliff'...
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /home/q.neill/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com ...
...
Transferred: sent 4120, received 724232 bytes, in 0.2 seconds
Bytes per second: sent 21590.6, received 3795287.2
debug1: Exit status 0
trace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all'
trace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'