Git checkout双重破折号的含义

Question

此git命令中文件名之前双击的含义是什么？

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

他们是强制性的吗？它等同于

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

Answer 1

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

git checkout path/to/file.txt

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

git checkout master

糟糕！这改变了分支。 --将要签出的树与您要签出的文件分开。

git checkout -- master

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

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

git-checkout: Argument Disambiguation中记录了这一点。

Answer 2

双击＃34; - ＆＃34;意味着＆＃34;命令行标志的结束＆＃34;即它告诉前面的命令不要尝试解析命令行选项之后的内容。

Answer 3

请注意，由于Git 2.5（2015年第二季度）自变量包含通配符（--），因此您不需要'*'

一种帮助“ git <cmd> <revs> <pathspec>”命令行约定捕获错误键入路径的启发式方法是确保命令行后面的所有非rev参数都是工作树中文件的名称，但这意味着“ git grep $str -- \*.c”必须始终与“ --”区分开来，因为没有人理智地会创建一个文件名实际上是星号-点-see的文件。

Git 2.5松散了启发式声明，以声明用户可能希望为我们提供路径说明的通配符。

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

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

pathspec：使用通配符时避免使用“ --”

当命令行中缺少“ --”并且命令可以同时使用rev和path时，其想法是，如果一个参数可以同时被视为扩展的SHA-1和路径，则“ { {1}}”为必填项，否则git拒绝继续。
当前实现为：

• （1）如果参数是rev，则它一定不能存在于工作树中
• （2）否则，它必须存在于工作树中
• （3）否则为“ --”。

这些规则适用于文字路径，但是当涉及非文字路径规范时，几乎总是要求用户添加“ --”，因为它失败了（2）并且（1）实际上很少得到满足（例如，“ --”，如果有一个名为“ *.c”的引用，则满足（1）。

此补丁通过考虑“存在于工作树中”的任何有效（*.c）通配符pathspec来稍微修改了规则。
规则变为：

• （1）如果arg是一个rev，则它必须存在于工作树中或不是有效的通配符pathspec。
• （2）否则，它要么存在于工作树中，要么是通配符pathspec
• （3）否则为“ *”。

对于新规则，在涉及通配符pathspec的大多数情况下，不需要“ --”。

---

在Git 2.26（2020年第1季度）中，对区分歧义的逻辑进行了调整，以区分修订版本和pathspec，以使反斜杠转义的glob特殊字符不计入“通配符为pathspec”规则。

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

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

^{举报人：DavidBurström
签名人：杰夫·金}

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

--

不带双破折号。

但是用于检查通配符的规则实际上会查找任何特殊的glob。
这过于宽松，因为这意味着实际上不执行任何通配符匹配的模式（例如“ git rev-parse '*.c' ”）将被视为pathspec。

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

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

（DWIM: Do What I Mean）

请注意，我们根本没有测试28fcc0b71a中的原始功能。
因此，此补丁不仅可以测试这些极端情况，而且还可以对现有行为进行回归测试。