Does Git Add have a verbose switch

I am in the process of moving all my private an public repo's over to github. One of the decisions I have made is to only use the console as it means a smaller tooling footprint if I ever need to change PCs, etc.

I would be a huge user of console applications 开发者_Go百科and being new to git I decided to purchase Tekpub's Mastering Git series since it shows you how to intergrate git bash as a toolbar.

Everything is working fine except for the add all command which is:

git add .

It seems to be working but I don't get any indication of it working or not. Is there a verbose switch (I think that is what it would be called) that would say what files were tracked after the command is launched?

I am using Visual Studio 2010 with the standard install of git (Not Git extensions)

For some git-commands you can specify --verbose,

git 'command' --verbose

or

git 'command' -v

Make sure the switch is after the actual git command. Otherwise - it won't work!

Also useful:

git 'command' --dry-run 

I was debugging an issue with git and needed some very verbose output to figure out what was going wrong. I ended up setting the GIT_TRACE environment variable:

export GIT_TRACE=1
git add *.txt

You can also use these on the same line:

GIT_TRACE=1 git add *.txt

Output:

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

You can use git add -i to get an interactive version of git add, although that's not exactly what you're after. The simplest thing to do is, after having git added, use git status to see what is staged or not.

Using git add . isn't really recommended unless it's your first commit. It's usually better to explicitly list the files you want staged, so that you don't start tracking unwanted files accidentally (temp files and such).

Not only Git has a GIT_TRACE2 flag (since Git 2.25, Q2 2019), but now that trace can even tell you what parent process called Git.

With Git 2.34 (Q4 2021), trace2 logs learned to show parent process name to see in what context Git was invoked.

That is helpful when Git is called by an IDE.

See commit 2f732bf, commit b7e6a41 (21 Jul 2021) by Emily Shaffer (nasamuffin).
^{(Merged by Junio C Hamano -- gitster -- in commit 6f64eea, 24 Aug 2021)}

tr2: log parent process name

^{Signed-off-by: Emily Shaffer}

It can be useful to tell who invoked Git - was it invoked manually by a user via CLI or script? By an IDE? In some cases - like 'repo' tool - we can influence the source code and set the GIT_TRACE2_PARENT_SID environment variable from the caller process.
In 'repo''s case, that parent SID is manipulated to include the string "repo", which means we can positively identify when Git was invoked by 'repo' tool.
However, identifying parents that way requires both that we know which tools invoke Git and that we have the ability to modify the source code of those tools.
It cannot scale to keep up with the various IDEs and wrappers which use Git, most of which we don't know about.
Learning which tools and wrappers invoke Git, and how, would give us insight to decide where to improve Git's usability and performance.

Unfortunately, there's no cross-platform reliable way to gather the name of the parent process.
If procfs is present, we can use that; otherwise we will need to discover the name another way.
However, the process ID should be sufficient to look up the process name on most platforms, so that code may be shareable.

Git for Windows gathers similar information and logs it as a "data_json" event.
However, since "data_json" has a variable format, it is difficult to parse effectively in some languages; instead, let's pursue a dedicated "cmd_ancestry" event to record information about the ancestry of the current process and a consistent, parseable way.

Git for Windows also gathers information about more than one generation of parent.
In Linux further ancestry info can be gathered with procfs, but it's unwieldy to do so.
In the interest of later moving Git for Windows ancestry logging to the 'cmd_ancestry' event, and in the interest of later adding more ancestry to the Linux implementation - or of adding this functionality to other platforms which have an easier time walking the process tree - let's make 'cmd_ancestry' accept an array of parentage.

technical/api-trace2 now includes in its man page:

"cmd_ancestry"

This event contains the text command name for the parent (and earlier generations of parents) of the current process, in an array ordered from nearest parent to furthest great-grandparent. It may not be implemented on all platforms.

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

With Git 2.34 (Q4 2021), the tracing of process ancestry information has been enhanced.

See commit 2d3491b, commit 326460a, commit 6eccfc3, commit 48f6871, commit f2cc888, commit 7d9c80f (27 Aug 2021) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 76f5fdc, 20 Sep 2021)}

tr2: tr2: log N parent process names on Linux

^{Signed-off-by: Ævar Arnfjörð Bjarmason
Acked-by: Taylor Blau}

In 2f732bf ("tr2: log parent process name", 2021-07-21, Git v2.34.0 -- merge we started logging parent process names, but only logged all parents on Windows. on Linux only the name of the immediate parent process was logged.

Extend the functionality added there to also log full parent chain on Linux.

With Git 2.38 (Q3 2022), the verbose trace output has been enhanced to include output about configuration variables.

See commit 35ae40e, commit 050d0dc (12 Aug 2022) by Teng Long (dyrone).
^{(Merged by Junio C Hamano -- gitster -- in commit 10ccb50, 29 Aug 2022)}

api-trace2.txt: print config key-value pair

^{Signed-off-by: Teng Long}

It's supported to print "interesting" config key-value paire to tr2 log by setting "GIT_TRACE2_CONFIG_PARAMS" environment variable and the "trace2.configparam" config.

technical/api-trace2 now includes in its man page:

Config (def param) Events

Dump "interesting" config values to trace2 log.

We can optionally emit configuration events, see trace2.configparams in git config for how to enable it.

$ git config color.ui auto

Then, mark the config color.ui as "interesting" config with
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

You can combine that with other runtime trace2 events:

tr2: shows scope unconditionally in addition to key-value pair

^{Signed-off-by: Teng Long}

When we specify GIT_TRACE2_CONFIG_PARAMS or trace2.configparams, trace2 will prints "interesting" config values to log.
Sometimes, when a config set in multiple scope files, the following output looks like (the irrelevant fields are omitted here as "..."):

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

As the log shows, even each config in different scope is dumped, but we don't know which scope it comes from.
Therefore, it's better to add the scope names as well to make them be more recognizable.

As an example of trace combination:

For example, when execute:

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

The following is the output (the irrelevant fields are omitted here as "..."):

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"}