在 Git 中，`--`（破折号）是什么意思？

In Git, what does `--` (dash dash) mean?

提问by SerMetAla

When reading the man pages for Git commands, you will often see an optional --(dash dash). In my experience, the --is not necessary and makes no difference. When do you need it? What does it mean in general, given that it appears in so many commands?

在阅读 Git 命令的手册页时，您经常会看到一个可选的--（破折号）。根据我的经验，--没有必要并且没有区别。你什么时候需要它？鉴于它出现在这么多命令中，它通常意味着什么？

回答by Dave

The double dash --in git means different things to different commands, but in general it separates options from parameters.

--git 中的双破折号对于不同的命令意味着不同的东西，但通常它将选项与参数分开。

In gitspecifically, the meaning of --depends on which subcommand you are using it with. It usually separates subcommand arguments (like the branch name in git checkout) from revisions or filenames. Sometimes it is completely optional, and used only to prevent an unusual filename being interpreted as program options.

特别是在git 中， 的含义--取决于您使用它的子命令。它通常将子命令参数（如 中的分支名称git checkout）与修订或文件名分开。有时它是完全可选的，仅用于防止将不寻常的文件名解释为程序选项。

For Example

例如

• git checkout. To check out a "commit" (referred to as "tree-ish" in the manual, because you can actually specify a range of object types) you use

  git checkout <commit>

  To refine the checkout to just a file or two, use --to separate the "tree-ish" parameters from the "filenames" you wish to check out.

• git commit. To commit whatever is in the "index" (ie, what you have staged via git add, simply issue the git commitcommand.

  git commit[-m message]

  To ignore whatever you have added via git addand commit the changes in a specific file, use git commit -- <filename>

• git add. To commit a file whose name begins with a -or a --, you must tell git add to stop reading parameters, and start reading filenames; --does that.

  git add -- -sample.txt

• git log. To see the commit history restricted to only commits affecting a file use

  git log -- filename

• git checkout. 要检查“提交”（在手册中称为“树形”，因为您实际上可以指定一系列对象类型），请使用

  git checkout <commit>

  要将签出细化为一两个文件，请使用--将“树形”参数与您希望签出的“文件名”分开。

• git commit. 要提交“索引”中的任何内容（即，您通过 暂存的内容git add，只需发出git commit命令。

  git commit[-m 消息]

  要忽略您通过添加的任何内容git add并提交特定文件中的更改，请使用 git commit -- <filename>

• git add. 要提交名称以 a-或 a开头的文件--，您必须告诉 git add 停止读取参数，并开始读取文件名；--这样做。

  git add -- -sample.txt

• git log. 查看仅限于影响文件使用的提交的提交历史

  git log -- filename

You need to check the man pages for any git command you use if you need to understand its specific meaning.

如果您需要了解其特定含义，则需要检查您使用的任何 git 命令的手册页。

回答by VonC

This question asks for a conceptual understanding of the double-dash across all git commands.

这个问题要求对所有 git 命令中的双破折号有一个概念性的理解。

The double-dash, which signals the end of options, has been recognized as "not enough" for Git.

双破折号表示选项的结束，已被认为对 Git 来说“不够”。

With Git 2.24 (Q3 2019), the command line parser learned the "--end-of-options" notation:

在 Git 2.24（2019 年第三季度）中，命令行解析器学习了“ --end-of-options” 符号：

The standard convention for scripters to have hardcoded set of options first on the command line, and force the command to treat end-user input as non-options, has been to use "--" as the delimiter, but that would not work for commands that use "--" as a delimiter between revs and pathspec.

脚本编写者首先在命令行上硬编码一组选项并强制命令将最终用户输入视为非选项的标准约定是使用“ --”作为分隔符，但这不适用于以下命令使用“ --”作为 revs 和 pathspec 之间的分隔符。

See commit 67feca3, commit 51b4594, commit 19e8789(06 Aug 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster--in commit 4a12f89, 09 Sep 2019)}

请参阅Jeff King ( ) 的commit 67feca3、commit 51b4594、commit 19e8789（2019 年 8 月 6 日）。^{（由Junio C Hamano合并-- --在提交 4a12f89 中，2019 年 9 月 9 日）}peff
gitster

revision: allow --end-of-optionsto end option parsing

There's currently no robust way to tell Git that a particular option is meant to be a revision, and not an option.
So if you have a branch "refs/heads/--foo", you cannot just say:

git rev-list --foo

You can say:

git rev-list refs/heads/--foo

But that breaks down if you don't know the refname, and in particular if you're a script passing along a value from elsewhere.
In most programs, you can use "--" to end option parsing, like this:

some-prog -- "$revision"

But that doesn't work for the revision parser, because "--" is already meaningful there: it separates revisions from pathspecs.
So we need some other marker to separate options from revisions.

This patch introduces "--end-of-options", which serves that purpose:

git rev-list --oneline --end-of-options "$revision"

will work regardless of what's in "$revision" (well, if you say "--" it may fail, but it won't do something dangerous, like triggering an unexpected option).

The name is verbose, but that's probably a good thing; this is meant to be used for scripted invocations where readability is more important than terseness.

One alternative would be to introduce an explicit option to mark a revision, like:

git rev-list --oneline --revision="$revision"

That's slightly moreinformative than this commit (because it makes even something silly like "--" unambiguous). But the pattern of using a separator like "--" is well established in git and in other commands, and it makes some scripting tasks simpler like:

git rev-list --end-of-options "$@"

revision: 允许--end-of-options结束选项解析

目前没有可靠的方法告诉 Git 一个特定的选项是一个修订版，而不是一个选项。
所以如果你有一个分支“ refs/heads/--foo”，你不能只说：

git rev-list --foo

你可以说：

git rev-list refs/heads/--foo

但是，如果您不知道 refname，特别是如果您是一个从其他地方传递值的脚本，那么这就会失败。
在大多数程序中，您可以使用“ --”来结束选项解析，如下所示：

some-prog -- "$revision"

但这对修订解析器不起作用，因为“ --”在那里已经有意义：它将修订与路径规范分开。
所以我们需要一些其他标记来将选项与修订分开。

此补丁引入了“ --end-of-options”，用于此目的：

git rev-list --oneline --end-of-options "$revision"

无论“$revision”中的内容如何，​​它都可以工作（好吧，如果你说“ --”，它可能会失败，但它不会做一些危险的事情，比如触发一个意外的选项）。

这个名字很冗长，但这可能是件好事；这旨在用于可读性比简洁更重要的脚本调用。

一种替代方法是引入一个显式选项来标记修订，例如：

git rev-list --oneline --revision="$revision"

这比这次提交提供的信息稍微多一点（因为它甚至可以使诸如“--”之类的愚蠢内容明确无误）。但是--在 git 和其他命令中使用像 " "这样的分隔符的模式已经很好地建立了，它使一些脚本任务更简单，例如：

git rev-list --end-of-options "$@"

---

---

parse-options: allow --end-of-optionsas a synonym for "--"

The revision option parser recently learned about --end-of-options, but that's not quite enough for all callers.
Some of them, like git-log, pick out some options using parse_options(), and then feed the remainder to setup_revisions().
For those cases we need to stop parse_options()from finding more options when it sees --end-of-options, and to retain that option in argvso that setup_revisions()can see it as well.

Let's handle this the same as we do "--". We can even piggy-back on the handling of PARSE_OPT_KEEP_DASHDASH, because any caller that wants to retain one will want to retain the other.

解析选项：允许--end-of-options作为“--”的同义词

修订选项解析器最近了解到--end-of-options，但这对所有调用者来说还不够。
其中一些，例如git-log，使用 挑选出一些选项parse_options()，然后将其余部分提供给setup_revisions()。
对于这些情况，我们需要parse_options()在看到 时停止查找更多选项--end-of-options，并保留该选项argv以便也setup_revisions()可以看到它。

让我们像处理“ --”一样处理这个问题。我们甚至可以捎带处理PARSE_OPT_KEEP_DASHDASH，因为任何想要保留一个的调用者都希望保留另一个。

Example:

例子：

git update-ref refs/heads/--source HEAD &&\
git log --end-of-options --source