为什么git帮助添加“git-”每个命令名称之前？ [英] Why does git help add "git-" before every command name?

问题描述

如果我需要关于 git status 命令的帮助，我可以输入 git help status 和一个帮助页面返回的名称是 git-status 。但是 git-status 不是命令，命令是带有空格的 git status ，而不是连字符。

如果我输入 git-status 或 git git-status 我得到一个错误。那么，为什么帮助页面将它称为 git-status ？

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

解决方案

注意，在开始阶段（2005-2008，Git 1.6.0），git子命令被引用为 git-xxx ，位于 $ PATH 中。

请参阅 Git 1.6.0发行说明：

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

从命令行调用git子命令为 git-xyzzy 自2006年初以来已被弃用在 1.5.4发行说明中正式公布）。
在将 git --exec-path >的输出添加到 $ PATH后，从脚本中使用它们在本版本中仍然受支持，但我们强烈建议用户将其脚本调整为使用 git xyzzy 表单，因为我们将停止安装 git-xyzzy 在以后的版本中用于内置命令的硬链接。

2006年线程增加：

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

我们没有 bindir vs execdir distinc但我们希望有一天可以以
的方式将所有内容都放入 bindir 。

As>解决方案的一部分，git 包装被发明出来，并且作为这种努力的
结果，脚本的某些部分以及许多
文档页面和示例脚本丢失了破折号。

历史上，git工具一直希望在用户的 PATH git - * 到
>，我们惊讶地看到 / usr / bin 中有100多个 git - *
命令。

这就是为什么要发明git包装器和 GIT_EXEC_PATH 环境的原因。

人们可以有 / usr / bin / git ，并且没有其他 git - * 在它们的 PATH 上，因为那个git知道在哪里找到其余的 git - * 命令。

为了达到这个目的，脚本应该知道在哪里找到剩下的部分 - 最简洁的方法是通过git foo表单运行其他脚本。

一致性通过 s / git-foo / git foo / g 是目标，但是那种
的变化干扰了真正的
工作的其他补丁，这实在太无聊了，所以没有人会批准
清理所有脚本。

If I want help on the git status command, I can enter git help status, and a help page is returned that says the name is "git-status". But "git-status" is not the command, the command is git status with a space, not a hyphen.

If I enter git-status or git git-status I get an error. So why does the help page call it git-status?

Git does this same thing with every command in the help pages. Why?

解决方案

Note that for in the beginning (2005-2008, Git 1.6.0), the git subcommands were referenced as git-xxx, in your $PATH.

See Git 1.6.0 release notes:

With the default Makefile settings, most of the programs are now installed outside your $PATH, except for "git", "gitk" and some server side programs that need to be accessible for technical reasons.

Invoking a git subcommand as "git-xyzzy" from the command line has been deprecated since early 2006 (and officially announced in 1.5.4 release notes).
Use of them from your scripts after adding output from "git --exec-path" to the $PATH is still supported in this release, but users are again strongly encouraged to adjust their scripts to use "git xyzzy" form, as we will stop installing "git-xyzzy" hardlinks for built-in commands in later releases.

This 2006 thread adds:

I think some historical background is in order.

We started without bindir vs execdir distinction but we wanted a way to someday migrate out of putting everything in bindir.
As > one part of the solution, "git" wrapper was invented, and as the result of that effort, some parts of the scripts, and lot of documentation pages and sample scripts, lost dashes.

Historically, git tools have always wanted everything git-* to be found on user's PATH, and we were alarmed to see 100+ git-* commands in /usr/bin.
That's why "git" wrapper and GIT_EXEC_PATH environment were invented.

People can have /usr/bin/git and no other git-* on their PATH, because that "git" knows where to find the rest of git-* commands.
For that to work, the scripts should know where to find the rest -- and cleanest way is to run others via "git foo" form.

Consistency via s/git-foo/git foo/g is the goal, but that kind of change interferes with the other patches that do the real work, and it is kind of boring, so nobody has done wholesale clean-up of all the scripts.

这篇关于为什么git帮助添加“git-”每个命令名称之前？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！