Git Add是否有详细的开关

Question

我正在将我的所有私人公共回购转移到github.我做出的决定之一就是只使用控制台,因为如果我需要更换PC等,它意味着更小的工具占用空间.

我将成为控制台应用程序的巨大用户并且是git的新用户我决定购买Tekpub的Mastering Git系列,因为它向您展示了如何将git bash整合为工具栏.

一切正常,除了add all命令,它是:

git add .

它似乎工作,但我没有任何迹象表明它是否有效.是否有一个详细的开关(我认为这就是所谓的),可以说在命令启动后跟踪了哪些文件？

我使用Visual Studio 2010与标准安装的git(非Git扩展)

Answer 1

对于一些你可以指定的git命令--verbose,

git 'command' --verbose

要么

git 'command' -v.

确保开关位于实际的git命令之后.否则 - 它将无法正常工作!

也很有用:

git 'command' --dry-run 

Answer 2

我正在调试git的问题，需要一些非常详细的输出来找出问题所在。我最终设置了GIT_TRACE环境变量：

export GIT_TRACE=1
git add *.txt

输出：

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

好吧,就像(几乎)每个类似unix的系统的控制台程序一样,如果命令成功,git不会告诉你任何事情.只有在出现问题时才打印出来.

但是,如果您想确定刚刚发生的事情,请输入

git status

并查看将要提交哪些更改以及哪些更改.我建议你在每次提交之前使用它,以确保你没有忘记任何事情.

由于你似乎是git的新手,这里有一个免费的在线书籍链接,介绍你git.它非常有用,它描述了基础知识以及众所周知的不同工作流程:http://git-scm.com/book

Answer 4

您可以使用git add -i获得的交互式版本git add，尽管这并不完全是您想要的。最简单的事情是在完成git added之后，使用git status来查看是否上演了什么。

git add .除非您是第一次提交，否则实际上不建议使用。通常最好明确列出要暂存的文件，以免意外开始跟踪不需要的文件（临时文件等）。

Answer 5

Git 不仅有 GIT_TRACE2 标志（自 Git 2.25，2019年第二季度起），而且现在该跟踪甚至可以告诉您哪个父进程称为 Git。

\n

在 Git 2.34（2021 年第 4 季度）中，trace2 日志学会了显示父进程名称，以查看在什么上下文中调用了 Git。

\n

当 IDE 调用 Git 时，这很有帮助。

\n

请参阅Emily Shaffer提交的提交 2f732bf和提交 b7e6a41（2021 年 7 月 21 日） ( )。\n ^{（由Junio C Hamano 合并 -- --在提交 6f64eea中，2021 年 8 月 24 日）}nasamuffin
gitster

\n

\n

tr2: 记录父进程名称

\n

^{签署人：艾米丽·谢弗}

\n

\n

\n

判断谁调用了 Git 非常有用 - 是由用户通过 CLI 或脚本手动调用的吗？通过 IDE？在某些情况下 - 例如“repo”工具 - 我们可以影响源代码并GIT_TRACE2_PARENT_SID从调用者进程设置环境变量。
\n在“repo”的情况下，该父 SID 被操纵以包含字符串“repo”，这意味着我们可以明确地识别“repo”工具何时调用 Git。
\n但是，以这种方式识别父母需要我们知道哪些工具调用 Git，并且我们有能力修改这些工具的源代码。
\n它无法扩展以跟上使用 Git 的各种 IDE 和包装器，其中大部分我们都不了解。
\n了解哪些工具和包装器调用 Git 以及如何调用，将使我们能够深入了解如何提高 Git 的可用性和性能。

\n

不幸的是，没有跨平台的可靠方法来收集父进程的名称。
\n如果procfs存在，我们可以使用它；否则我们将需要以另一种方式发现这个名字。
\n但是，进程 ID 应足以在大多数平台上查找进程名称，以便代码可以共享。

\n

Git for Windows 收集类似的信息并将其记录为"data_json"事件。
\n然而，由于"data_json"格式可变，在某些语言中很难有效解析；相反，让我们追求一个专门的"cmd_ancestry"事件来记录有关当前进程的祖先的信息，并以一致的、可解析的方式。

\n

Git for Windows 还收集不止一代父母的信息。
\n在 Linux 中，可以使用 收集更多祖先信息procfs，但这样做很不方便。
\n为了稍后将适用于 Windows 的 Git 祖先记录移至 \' cmd_ancestry\' 事件，并且为了以后向 Linux 实现添加更多祖先 - 或者将此功能添加到其他平台，以便更轻松地完成该过程树 - 让 \' cmd_ancestry\' 接受一个出身数组。

\n

\n

technical/api-trace2现在包含在其手册页中：

\n

\n

"cmd_ancestry"

\n

此事件包含当前进程的父进程（以及较早的父进程）的文本命令名称，该名称位于从最近的父进程到最远的曾祖进程的数组中。它可能并未在所有平台上实现。

\n

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

\n

\n\n

在 Git 2.34（2021 年第 4 季度）中，进程祖先信息的跟踪得到了增强。

\n

请参阅提交 2d3491b、提交 326460a、提交 6eccfc3、提交 48f6871、提交 f2cc888、提交 7d9c80f（2021 年 8 月 27 日），作者：\xc3\x86var Arnfj\xc3\xb6r\xc3\xb0 Bjarmason ( avar)。
\n ^{（由Junio C Hamano 合并 -- gitster--在提交 76f5fdc中，2021 年 9 月 20 日）}

\n

\n

tr2:: Linux 上tr2的log N父进程名称

\n

^{签署人：\xc3\x86var Arnfj\xc3\xb6r\xc3\xb0 Bjarmason}
\n^{确认人：Taylor Blau}

\n

\n

\n

2f732bf (" :日志父进程名"tr2 ,2021-07-21,Git v2.34.0 --合并 中，我们开始记录父进程名称，但仅记录 Windows 上的所有父进程名称。非 Linux 仅记录直接父进程的名称进程被记录。

\n

扩展此处添加的功能，以在 Linux 上记录完整的父链。

\n

\n\n

在 Git 2.38（2022 年第 3 季度）中，详细跟踪输出已得到增强，包括有关配置变量的输出输出。

\n

请参阅提交 35ae40e、提交 050d0dc（2022 年 8 月 12 日），作者：腾龙 ( dyrone)。
\n （由^{Junio C Hamano合并-- --在提交 10ccb50中gitster中，2022 年 8 月 29 日）}

\n

\n

api-trace2.txt：打印配置键值对

\n

^{签字人：腾龙}

\n

\n

\n

支持通过设置“ GIT_TRACE2_CONFIG_PARAMS”环境变量和“ ”来将“有趣的”配置键值对打印到tr2日志中trace2.configparam ”配置将“有趣”的配置键值对打印到tr2日志中。

\n

\n

technical/api-trace2现在包含在其手册页中：

\n

\n

Config (def param) Events

\n

将“有趣的”配置值转储到trace2日志。

\n

我们可以选择发出配置事件，请参阅\ntrace2.configparams以git config了解如何启用\n。

\n

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

\n

然后，使用\n将配置标记color.ui为“有趣”配置：
GIT_TRACE2_CONFIG_PARAMS

\n

$ git config color.ui auto\n

\n

\n

您可以将其与其他运行时trace2事件结合起来：

\n

\n

tr2：除了键值对之外，无条件显示范围

\n

^{签字人：腾龙}

\n

\n

\n

当我们指定GIT_TRACE2_CONFIG_PARAMSor时trace2.configparams，trace2 将打印“有趣的”配置值来记录。
\n有时，当在多个作用域文件中设置配置时，输出如下所示（此处省略不相关字段为“...”）：

\n

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

\n

正如日志所示，即使不同范围内的每个配置都被转储，但我们不知道它来自哪个范围。
\n因此，最好也添加范围名称以使它们更易于识别。

\n

\n

作为跟踪组合的示例：

\n

\n

例如执行时：

\n

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

\n

输出如下（不相关字段省略为“ ...”）：

\n

Format normal:\n... git.c:461 ... def_param scope:system core.multipackindex=false\n... git.c:461 ... def_param scope:global core.multipackindex=false\n... git.c:461 ... def_param scope:local core.multipackindex=false\n\n\nFormat perf:\n\n... | def_param    | ... | scope:system | core.multipackindex:false\n... | def_param    | ... | scope:global | core.multipackindex:false\n... | def_param    | ... | scope:local  | core.multipackindex:false\n\nFormat event:\n\n{"event":"def_param", ... ,"scope":"system","param":"core.multipackindex","value":"false"}\n{"event":"def_param", ... ,"scope":"global","param":"core.multipackindex","value":"false"}\n{"event":"def_param", ... ,"scope":"local","param":"core.multipackindex","value":"false"}\n

\n

\n