Git Add dispose-t-il d'un bouton "verbose" ?

Question

Je suis en train de transférer tous mes repo privés et publics sur github. L'une des décisions que j'ai prises est de n'utiliser que la console, ce qui permet de réduire l'empreinte de l'outillage si je dois changer de PC, etc.

J'ai décidé d'acheter la série Mastering Git de Tekpub car elle montre comment intégrer git bash dans une barre d'outils.

Tout fonctionne bien sauf la commande add all qui est :

git add .

Il semble fonctionner, mais je n'obtiens aucune indication à ce sujet. Existe-t-il un commutateur "verbose" (je pense que c'est ainsi qu'on l'appelle) qui indiquerait quels fichiers ont été suivis après le lancement de la commande ?

J'utilise Visual Studio 2010 avec l'installation standard de git (pas les extensions Git).

Answer 1

Pour certains git-commands, vous pouvez spécifier --verbose ,

git 'command' --verbose

ou

git 'command' -v

Assurez-vous que le commutateur se trouve après la commande git. Sinon, cela ne fonctionnera pas !

Également utile :

git 'command' --dry-run

Answer 2

J'étais en train de déboguer un problème avec git et j'avais besoin d'une sortie très verbeuse pour comprendre ce qui n'allait pas. J'ai fini par paramétrer l'option GIT_TRACE variable d'environnement :

export GIT_TRACE=1
git add *.txt

Vous pouvez également les utiliser sur la même ligne :

GIT_TRACE=1 git add *.txt

Sortie :

14:06:05.508517 git.c:415               trace: built-in: git add test.txt test2.txt
14:06:05.544890 git.c:415               trace: built-in: git config --get oh-my-zsh.hide-dirty

Answer 3

Vous pouvez utiliser git add -i pour obtenir une version interactive de git add bien que ce ne soit pas exactement ce que vous recherchez. La chose la plus simple à faire est, après avoir git add ed, utiliser git status pour savoir ce qui est mis en scène ou non.

Utilisation git add . n'est pas vraiment recommandé, sauf s'il s'agit de votre premier commit. Il est généralement préférable de lister explicitement les fichiers que vous voulez mettre en scène, afin de ne pas commencer à suivre des fichiers non désirés accidentellement (fichiers temporaires et autres).

Answer 4

Non seulement Git dispose d'un drapeau GIT_TRACE2 ( depuis Git 2.25 (Q2 2019), mais maintenant cette trace peut même vous dire quel processus parental s'appelle Git.

Avec Git 2.34 (Q4 2021), les logs trace2 ont appris à montrer le nom du processus parent pour voir dans quel contexte Git a été invoqué.

Cela est utile lorsque Git est appelé par un IDE.

Voir commit 2f732bf , commit b7e6a41 (21 Jul 2021) par Emily Shaffer ( nasamuffin ) .
(fusionné par Junio C Hamano -- gitster -- en commit 6f64eea , 24 août 2021)

tr2 Nom du processus parent d'enregistrement

Signé par : Emily Shaffer

Il peut être utile de savoir qui a invoqué Git - a-t-il été invoqué manuellement par un utilisateur via CLI ou script ? Par un IDE ? Dans certains cas - comme l'outil 'repo' - nous pouvons influencer le code source et définir le paramètre GIT_TRACE2_PARENT_SID de la variable d'environnement du processus appelant.
Dans le cas de 'repo', ce SID parent est manipulé pour inclure la chaîne "repo", ce qui signifie que nous pouvons identifier avec certitude quand Git a été invoqué par l'outil 'repo'.
Cependant, pour identifier les parents de cette manière, il faut à la fois savoir quels outils invoquent Git et avoir la possibilité de modifier le code source de ces outils.
Il n'est pas en mesure de suivre l'évolution des différents IDE et wrappers qui utilisent Git, dont la plupart nous sont inconnus.
Le fait de savoir quels outils et quels wrappers invoquent Git, et comment, nous permettrait de décider où améliorer la convivialité et les performances de Git.

Malheureusement, il n'existe pas de moyen fiable et multiplateforme de recueillir le nom du processus parent.
Si procfs est présent, nous pouvons l'utiliser ; sinon, nous devrons découvrir le nom d'une autre manière.
Toutefois, l'identifiant du processus devrait être suffisant pour permettre de rechercher le nom du processus sur la plupart des plateformes, de sorte que le code puisse être partagé.

Git pour Windows recueille des informations similaires et les enregistre en tant que "data_json" événement.
Toutefois, étant donné que les "data_json" a un format variable, il est difficile de l'analyser efficacement dans certains langages. "cmd_ancestry" pour enregistrer des informations sur l'origine du processus en cours et de manière cohérente et analysable.

Git pour Windows recueille également des informations sur plusieurs générations de parents.
Sous Linux, d'autres informations sur les ancêtres peuvent être recueillies à l'aide de procfs mais il est difficile de le faire.
Dans l'intérêt de déplacer plus tard l'enregistrement de l'ascendance de Git pour Windows vers l'espace ' cmd_ancestry et dans l'intérêt d'ajouter plus tard plus d'ascendance à l'implémentation Linux - ou d'ajouter cette fonctionnalité à d'autres plates-formes qui ont plus de facilité à parcourir l'arbre de processus - rendons ' cmd_ancestry Accepter un tableau de parenté.

technical/api-trace2 inclut désormais dans son page de manuel :

"cmd_ancestry"

Cet événement contient le nom de la commande texte pour la commande parent (et les commandes antérieures de générations précédentes de parents) du processus en cours, dans un tableau classé par ordre de du parent le plus proche à l'arrière-grand-parent le plus éloigné. Il se peut qu'il ne soit pas implémenté sur toutes les plateformes.

{
"event":"cmd_ancestry",
...
"ancestry":["bash","tmux: server","systemd"]
}

---

Avec Git 2.34 (Q4 2021), la traçabilité des informations sur l'ascendance des processus a été améliorée.

Voir commit 2d3491b , commit 326460a , commit 6eccfc3 , commit 48f6871 , commettre f2cc888 , commit 7d9c80f (27 août 2021) par Ævar Arnfjörð Bjarmason ( avar ) .
(fusionné par Junio C Hamano -- gitster -- en commit 76f5fdc , 20 Sep 2021)

tr2 : tr2 : log N noms des processus parents sous Linux

Signé par : Ævar Arnfjörð Bjarmason
Par : Taylor Blau

En 2f732bf (" tr2 : nom du processus parent du journal", 2021-07-21, Git v2.34.0 -- fusionner nous avons commencé à enregistrer les noms des processus parents, mais seulement tous les parents sous Windows. sous Linux, seul le nom du processus parent immédiat était enregistré.

Étendre la fonctionnalité ajoutée à l'enregistrement de la chaîne parentale complète sur les sites suivants Linux.

---

Avec Git 2.38 (Q3 2022), la sortie de la trace verbose a été améliorée pour inclure la sortie concernant les éléments suivants variables de configuration .

Voir commit 35ae40e , Engagement 050d0dc (12 août 2022) par Teng Long ( dyrone ) .
(fusionné par Junio C Hamano -- gitster -- en commit 10ccb50 , 29 août 2022)

api-trace2.txt : impression de la paire clé-valeur de la configuration

Signé par : Teng Long

Il est possible d'imprimer la paire clé-valeur de configuration "intéressante" dans le journal tr2 en définissant " GIT_TRACE2_CONFIG_PARAMS "et la variable d'environnement " trace2.configparam " config.

technical/api-trace2 inclut désormais dans son page de manuel :

Config (def param) Events

Dépose les valeurs de configuration "intéressantes" dans le journal trace2.

Nous pouvons optionnellement émettre des événements de configuration, voir trace2.configparams en git config pour savoir comment activer la fonction l'activer.

$ git config color.ui auto

Ensuite, marquez la configuration color.ui comme une configuration "intéressante" avec
GIT_TRACE2_CONFIG_PARAMS :

$ export GIT_TRACE2_PERF_BRIEF=1
$ export GIT_TRACE2_PERF=~/log.perf
$ export GIT_TRACE2_CONFIG_PARAMS=color.ui
$ git version
...
$ cat ~/log.perf
d0 | main                     | version      |     |           |           |              | ...
d0 | main                     | start        |     |  0.001642 |           |              | /usr/local/bin/git version
d0 | main                     | cmd_name     |     |           |           |              | version (version)
d0 | main                     | def_param    |     |           |           |              | color.ui:auto
d0 | main                     | data         | r0  |  0.002100 |  0.002100 | fsync        | fsync/writeout-only:0
d0 | main                     | data         | r0  |  0.002126 |  0.002126 | fsync        | fsync/hardware-flush:0
d0 | main                     | exit         |     |  0.002142 |           |              | code:0
d0 | main                     | atexit       |     |  0.002161 |           |              | code:0

Vous pouvez combiner cela avec d'autres événements d'exécution trace2 :

tr2 : indique la portée inconditionnellement en plus de la paire clé-valeur

Signé par : Teng Long

Lorsque nous spécifions GIT_TRACE2_CONFIG_PARAMS ou trace2.configparams trace2 imprime les valeurs de configuration "intéressantes" dans le journal.
Parfois, lorsqu'une configuration est définie dans plusieurs fichiers d'étendue, la sortie suivante se présente comme suit (les champs non pertinents sont omis ici sous la forme de "...") :

...`|` `def_param`    `|`  ...  
`|` core.multipackindex:false ...`|` `def_param`    `|`  ...  
`|` core.multipackindex:false ...`|` `def_param`    `|`  ...  
`|` core.multipackindex:false  

Comme le montre le journal, même chaque configuration dans un périmètre différent est vidée, mais nous ne savons pas laquelle. champ d'application il provient.
Il est donc préférable d'ajouter les noms des champs d'application afin de les rendre plus reconnaissables.

Exemple de combinaison de traces :

Par exemple, lors de l'exécution :

$ GIT_TRACE2_PERF=1 \
  GIT_TRACE2_CONFIG_PARAMS=core.multipackIndex \
  git rev-list --test-bitmap HEAD"

Le résultat est le suivant (les champs non pertinents sont omis ici sous la forme " ... ") :

Format normal:
... git.c:461 ... def_param scope:system core.multipackindex=false
... git.c:461 ... def_param scope:global core.multipackindex=false
... git.c:461 ... def_param scope:local core.multipackindex=false

Format perf:

... | def_param    | ... | scope:system | core.multipackindex:false
... | def_param    | ... | scope:global | core.multipackindex:false
... | def_param    | ... | scope:local  | core.multipackindex:false

Format event:

{"event":"def_param", ... ,"scope":"system","param":"core.multipackindex","value":"false"}
{"event":"def_param", ... ,"scope":"global","param":"core.multipackindex","value":"false"}
{"event":"def_param", ... ,"scope":"local","param":"core.multipackindex","value":"false"}

Answer 5

Eh bien, comme (presque) tous les programmes de console pour les systèmes de type Unix, git ne vous dit rien si une commande réussit. Il n'affiche quelque chose que si quelque chose ne va pas.

Toutefois, si vous voulez être sûr de ce qui vient de se passer, tapez simplement

git status

et voir quelles modifications vont être validées et lesquelles ne le seront pas. Je vous suggère d'utiliser cette fonction avant chaque validation, juste pour être sûr de ne rien oublier.

Puisque vous semblez ne pas connaître git, voici un lien vers un livre en ligne gratuit qui vous initie à git. Il est très utile, il écrit sur les bases ainsi que sur les différents workflows bien connus : http://git-scm.com/book