为什么 git 帮助在每个命令名称前添加“git-”？

Question

如果我需要关于git status 命令的帮助，我可以输入git help status，然后返回一个帮助页面，显示名称为“git-status”。但是“git-status”不是命令，命令是git status带空格，不是连字符。

如果我输入 git-status 或 git git-status 我会收到错误消息。那么为什么帮助页面叫它git-status呢？

Git 对帮助页面中的每个命令都执行相同的操作。为什么？

Answer 1

请注意，在开始时（2005-2008，Git 1.6.0），git 子命令在您的 $PATH 中被引用为 git-xxx。

见Git 1.6.0 release notes:

使用默认的Makefile 设置，现在大多数程序 安装在您的 $PATH 之外，“git”、“gitk”和一些出于技术原因需要访问的服务器端程序除外。

从命令行调用 git 子命令为“git-xyzzy”自 2006 年初以来已被弃用（并在 1.5.4 release notes 中正式宣布）。
此版本仍支持在将“git --exec-path”的输出添加到$PATH 后从脚本中使用它们，但再次强烈建议用户调整其脚本以使用“git xyzzy”形式，因为我们将停止在以后的版本中为内置命令安装“git-xyzzy”硬链接。

这个2006 thread adds：

我认为一些历史背景是有序的。

我们一开始没有 bindir 与 execdir 的区别，但我们想要一个 有朝一日摆脱把所有东西都放在bindir中的方法。
作为解决方案的一部分，发明了“git”包装器，并且作为 努力的结果，脚本的某些部分，还有很多 文档页面和示例脚本，丢失的破折号。

从历史上看，git 工具一直想要 git-* 的所有内容 可以在用户的​​PATH 上找到，我们惊恐地看到 100+ git-* /usr/bin.
中的命令 这就是发明“git”包装器和GIT_EXEC_PATH 环境的原因。

人们的PATH 上可以有/usr/bin/git 而没有其他git-*，因为那个“git”知道在哪里可以找到其余的git-* 命令。
为此，脚本应该知道在哪里可以找到其余部分——最干净的方法是通过“git foo”表单运行其他脚本。

通过s/git-foo/git foo/g 实现一致性是目标，但是那种 of change 干扰了其他真正的补丁 工作，有点无聊，所以没有人做批发 清理所有脚本。

---

在 Git 2.29（2020 年第四季度）中，安装过程学会了为每个“foo”内置子命令选择性地省略“git-foo”可执行文件，这仅适用于仍然依赖时代的老前辈古老的承诺，在他们的脚本早期将“git --exec-path”输出添加到PATH 将使他们编写的“git-foo”调用保持工作。

从磁盘中删除这些可执行文件的旧尝试在 1.6 时代失败了；以后可能值得再次尝试。

参见Johannes Schindelin (dscho) 的commit ef60e9f、commit 179227d、commit a8b5355（2020 年 9 月 21 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 94de88c，2020 年 10 月 4 日）}

Git:可选择跳过链接/复制内置函数

^{签字人：约翰内斯·辛德林}

很长一段时间以来，内置的非破折号形式是编写脚本的推荐方式，即最好调用git merge [...]^(man)拨打git-merge [...]。

虽然 Git 仍然支持虚线形式（通过将 git 可执行文件硬链接到 libexec/git-core/ 中的虚线名称），但实际上它可能几乎无关紧要。

但是，我们确实关心保持人们的脚本正常工作（即使它们是在开始推荐非破折号形式之前编写的）。

不过，保持这种向后兼容性并不一定便宜：即使在 git.git 结帐中修改提示提交也需要重新链接所有这些虚线命令。
在此开发人员的笔记本电脑上，这会产生明显的不同：

$ touch version.c && time make
    CC version.o
    AR libgit.a
    LINK git-bugreport.exe
    [... 11 similar lines ...]
    LN/CP git-remote-https.exe
    LN/CP git-remote-ftp.exe
    LN/CP git-remote-ftps.exe
    LINK git.exe
    BUILTIN git-add.exe
    [... 123 similar lines ...]
    BUILTIN all
    SUBDIR git-gui
    SUBDIR gitk-git
    SUBDIR templates
    LINK t/helper/test-fake-ssh.exe
    LINK t/helper/test-line-buffer.exe
    LINK t/helper/test-svn-fe.exe
    LINK t/helper/test-tool.exe



real    0m36.633s
user    0m3.794s
sys     0m14.141s



$ touch version.c && time make SKIP_DASHED_BUILT_INS=1
    CC version.o
    AR libgit.a
    LINK git-bugreport.exe
    [... 11 similar lines ...]
    LN/CP git-remote-https.exe
    LN/CP git-remote-ftp.exe
    LN/CP git-remote-ftps.exe
    LINK git.exe
    BUILTIN git-receive-pack.exe
    BUILTIN git-upload-archive.exe
    BUILTIN git-upload-pack.exe
    BUILTIN all
    SUBDIR git-gui
    SUBDIR gitk-git
    SUBDIR templates
    LINK t/helper/test-fake-ssh.exe
    LINK t/helper/test-line-buffer.exe
    LINK t/helper/test-svn-fe.exe
    LINK t/helper/test-tool.exe



real    0m23.717s
user    0m1.562s
sys     0m5.210s

此外，.zip 文件对硬链接没有任何标准化支持，因此“压缩”可执行文件将导致磁盘使用量膨胀。 （为了减小 Windows 版 Git 的“MinGit”变体的大小，它以.zip 文件的形式分发，硬链接被特别排除在外。）

除此之外，一些经常用于评估磁盘使用情况的程序未能意识到这些是硬链接，并且严重高估了磁盘使用情况。
最值得注意的是，直到最后几个 Windows 10 版本之前，Windows Explorer 都是这种情况。参见例如msysgit/msysgit issue 58.

为了节省硬链接这些虚线命令所需的时间，并计划最终停止在 Windows 上提供这些硬链接，让我们引入一个 Makefile 旋钮来跳过生成它们。

Answer 2

实际上有一个命令 git-status 和一个用于所有其他 git 命令的命令。您只是没有将 PATH 设置为这些命令，因为 git 就足够了。例如，在 Windows 中，您可以在此处找到所有命令可执行文件：C:\Program Files (x86)\Git\libexec\git-core。 Git 是以一种非常 unix 的方式开发的，其中包含许多简单的命令，这些命令只做一件事，但做对了。这仍然反映在帮助中，可能是出于历史原因。

Answer 3

正确答案是“历史”。

回到昏暗的时代（2005 年左右），每个 Git 命令都是一个单一的东西：

$ git-init
[initialized new repository ...]
$ git-add Makefile README
$ git-status
...
$ git-commit

不过，使用 bash 命令补全的人很快就会键入 git-TAB 并得到 47,981 个模糊的 git 命令，例如 git-block-area and git-hammer-branch（这些是编造的，但我希望能带来指出相当好:-)）。 It was time to divide things up into user oriented commands, called porcelain, and low-level commands used internally, called plumbing.

所有命令都被重命名，Git 添加了一个前端命令git。对于那些使用 bash 命令完成的人，bash 会读取一个“完成文件”，其中列出仅面向用户的瓷器命令。所以现在gitTAB 只列出了 30 到 40 个左右的命令，而不是 100 多个。

但是，所有文档都保留了历史格式。