Git checkout 双破折号的含义

Meaning of Git checkout double dashes

提问by mottalrd

What is the meaning of the double dashes before the file name in this git command?

这个 git 命令中文件名前的双破折号是什么意思？

git checkout --ours -- path/to/file.txt
git checkout --theirs -- path/to/file.txt

Are they mandatory? Is it equivalent to

它们是强制性的吗？是否相当于

git checkout --ours path/to/file.txt
git checkout --theirs path/to/file.txt

回答by Dietrich Epp

Suppose I have a file named path/to/file.txtin my Git repository, and I want to revert changes on it.

假设path/to/file.txt我的 Git 存储库中有一个文件，我想恢复对它的更改。

git checkout path/to/file.txt

Now suppose that the file is named master...

现在假设文件名为master...

git checkout master

Whoops! That changed branches instead. The --separates the tree you want to check out from the files you want to check out.

哎呀！而是改变了分支。将--要签出的树与要签出的文件分开。

git checkout -- master

It also helps us if some freako added a file named -fto our repository:

如果某些 freako 添加了一个名为-f我们存储库的文件，它也会对我们有所帮助：

git checkout -f      # wrong
git checkout -- -f   # right

This is documented in git-checkout: Argument Disambiguation.

这记录在git-checkout: Argument Disambiguation 中。

回答by timmcliu

The double dash "--" means "end of command line flags" i.e. it tells the preceding command not to try to parse what comes after command line options.

双破折号“--”表示“命令行标志结束”，即它告诉前面的命令不要尝试解析命令行选项之后的内容。

回答by VonC

Note that you would not need, since Git 2.5 (Q2 2015) a '--' if your argument includes wildcard (*)

请注意，您不需要，因为 Git 2.5（2015 年第二季度）--如果您的参数包含通配符 ( *)

An heuristic to help the "git <cmd> <revs> <pathspec>" command line convention to catch mistyped paths is to make sure all the non-rev parameters in the later part of the command line are names of the files in the working tree, but that means "git grep $str -- \*.c" must always be disambiguated with "--", because nobody sane will create a file whose name literally is asterisk-dot-see.

帮助 " git <cmd> <revs> <pathspec>" 命令行约定捕获错误输入路径的一种启发式方法是确保命令行后面部分中的所有非 rev 参数都是工作树中文件的名称，但这意味着 " git grep $str -- \*.c" 必须始终是用“ --”消除歧义，因为没有人会创建一个名称字面上是星号点见的文件。

Git 2.5 looses the heuristic to declare that with a wildcard string the user likely meant to give us a pathspec.

Git 2.5放弃了使用通配符字符串声明用户可能打算给我们一个 pathspec 的启发式。

git checkout 'a*'
# same as
git checkout -- 'a*'

See commit 28fcc0b(02 May 2015) by Duy Nguyen (nguyenlocduy).
^{(Merged by Junio C Hamano -- gitster--in commit 949d167, 19 May 2015)}

请参阅Duy Nguyen ( ) 的commit 28fcc0b（2015 年 5 月 2 日）。^{（由Junio C Hamano合并-- --在提交 949d167 中，2015 年 5 月 19 日）}nguyenlocduy
gitster

pathspec: avoid the need of "--" when wildcard is used

When "--" is lacking from the command line and a command can take both revs and paths, the idea is if an argument can be seen as both an extended SHA-1 and a path, then "--" is required or git refuses to continue.
It's currently implemented as:

• (1) if an argument is rev, then it must not exist in worktree
• (2) else, it must exist in worktree
• (3) else, "--" is required.

These rules work for literal paths, but when non-literal pathspec is involved, it almost always requires the user to add "--" because it fails (2) and (1) is really rarely met (take "*.c" for example, (1) is met if there is a ref named "*.c").

This patch modifies the rules a bit by considering any valid (*) wildcard pathspec "exist in worktree".
The rules become:

• (1) if an arg is a rev, then it must either exist in worktree or not be a valid wildcard pathspec.
• (2) else, it either exists in worktree or is a wildcard pathspec
• (3) else, "--" is required.

With the new rules, "--" is not needed most of the time when wildcard pathspec is involved.

pathspec:--使用通配符时避免需要“ ”

当--命令行中缺少" " 并且命令可以同时采用 revs 和路径时，想法是如果一个参数可以被视为扩展的 SHA-1 和路径，那么 " --" 是必需的，否则 git 拒绝继续。
它目前实现为：

• (1) 如果参数是 rev，则它不能存在于工作树中
• (2) 否则，它必须存在于工作树中
• (3) 否则，“ --”是必需的。

这些规则适用于文字路径，但是当涉及非文字路径规范时，它几乎总是要求用户添加“ --”，因为它失败（2）和（1）真的很少满足（以“ *.c”为例，（1）如果存在名为“ *.c”的引用，则满足。

此补丁通过考虑*“存在于工作树中”的任何有效 ( ) 通配符路径规范来稍微修改规则。
规则变成：

• (1) 如果 arg 是 rev，则它必须存在于工作树中或不是有效的通配符路径规范。
• (2) 否则，它要么存在于工作树中，要么是通配符路径规范
• (3) 否则，“ --”是必需的。

使用新规则，--当涉及通配符路径规范时，大多数时候不需要“ ”。

---

---

With Git 2.26 (Q1 2020), the disambiguation logic to tell revisions and pathspec apart has been tweaked so that backslash-escaped glob special characters do not count in the "wildcards are pathspec" rule.

在 Git 2.26（2020 年第一季度）中，区分修订和路径规范的消歧逻辑已经过调整，以便反斜杠转义的 glob 特殊字符不计入“通配符是路径规范”规则。

See commit 39e21c6(25 Jan 2020) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster--in commit 341f8a6, 12 Feb 2020)}

请参阅Jeff King ( ) 的commit 39e21c6(25 Jan 2020 )。^{（由Junio C Hamano合并-- --在commit 341f8a6，2020 年 2 月 12 日）}peff
gitster

verify_filename(): handle backslashes in "wildcards are pathspecs" rule

^{Reported-by: David Burstr?m
Signed-off-by: Jeff King}

Commit 28fcc0b71a(pathspec: avoid the need of "--" when wildcard is used, 2015-05-02) allowed:

git rev-parse '*.c'

without the double-dash.

But the rule it uses to check for wildcards actually looks for any glob special.
This is overly liberal, as it means that a pattern that doesn't actually do any wildcard matching, like "a\b", will be considered a pathspec.

If you do have such a file on disk, that's presumably what you wanted.
But if you don't, the results are confusing: rather than say "there's no such path a\b", we'll quietly accept it as a pathspec which very likely matches nothing (or at least not what you intended).
Likewise, looking for path "a\*b" doesn't expand the search at all; it would only find a single entry, "a*b".

This commit switches the rule to trigger only when glob metacharacters would expand the search, meaning both of those cases will now report an error (you can still disambiguate using "--", of course; we're just tightening the DWIM heuristic).

verify_filename()：处理“通配符是路径规范”规则中的反斜杠

^{报告人：David Burstr?m
签字人：Jeff King}

允许提交28fcc0b71a（pathspec：--使用通配符时避免使用“ ”，2015-05-02）：

git rev-parse '*.c'

没有双破折号。

但是它用来检查通配符的规则实际上是寻找任何特殊的glob。
这过于自由了，因为这意味着实际上不进行任何通配符匹配的模式（例如“ a\b”）将被视为路径规范。

如果您在磁盘上确实有这样的文件，那大概就是您想要的。
但是如果你不这样做，结果会令人困惑：而不是说“ there's no such path a\b”，我们会悄悄地接受它作为一个很可能不匹配的路径规范（或者至少不是你想要的）。
同样，查找路径“ a\*b”根本不会扩展搜索；它只会找到一个条目“ a*b”。

此提交将规则切换为仅在 glob 元字符会扩展搜索时触发，这意味着这两种情况现在都会报告错误（--当然，您仍然可以使用“ ”来消除歧义；我们只是加强了 DWIM 启发式）。

(DWIM: Do What I Mean)

（DWIM：按我的意思做）

Note that we didn't test the original feature in 28fcc0b71aat all.
So this patch not only tests for these corner cases, but also adds a regression test for the existing behavior.

请注意，我们根本没有测试28fcc0b71a中的原始功能。
所以这个补丁不仅测试了这些极端情况，还增加了对现有行为的回归测试。