Git签出双破折号的含义

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

git checkout path/to/file.txt

现在假设文件名为master…

git checkout master

哎呀!这反而改变了分支。--将你想要签出的树与你想要签出的文件分开。

git checkout -- master

如果某个怪人在我们的存储库中添加了一个名为-f的文件，它也会帮助我们:

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

这在参数消歧中有记录。

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

注意，从Git 2.5 (Q2 2015)开始，如果参数包含通配符(*)，则不需要'--'。

一个帮助“git <cmd> <revs> <pathspec>”命令行惯例捕捉输入错误路径的启发式方法是确保命令行后面部分的所有非rev参数都是工作树中的文件名称，但这意味着“git grep $str -- \*.c”必须始终与“--”消除歧义，因为任何理智的人都不会创建一个名称字面上是“* . see”的文件。

Git 2.5没有启发式地声明使用通配符字符串，用户可能意味着给我们一个路径规格.;

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

参见提交28 fcc0b (02 May 2015) by Duy Nguyen (nguyenlocduy) ^{(由Junio C Hamano—gitster—在提交949年d167中合并，2015年5月19日)}

pathspec:当使用通配符时，避免使用"--"

当命令行中缺少"--"，并且一个命令可以同时获得转速和路径时，如果一个参数可以被视为扩展的SHA-1和路径，那么就需要"--"，否则git拒绝继续 它目前实现为:

• (1)如果一个参数是rev，那么它必须不存在于工作树中
• (2)否则，它必须存在于工作树上
• (3)否则，"--"是必需的。

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

这个补丁通过考虑任何有效的(*)通配符路径spec“存在于工作树中”来修改规则 规则变成:

• (1)如果一个arg是一个rev，那么它必须要么存在于工作树中，要么不是一个有效的通配符路径spec。
• (2)否则，它要么存在于工作树中，要么是一个通配符路径spec
• (3)否则，"--"是必需的。

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

在Git 2.26 (Q1 2020)中，将修订版本和路径规范区分开来的消歧逻辑已经进行了调整，因此反斜杠转义的glob特殊字符在“通配符是路径规范”规则中不算数。

参见提交39 e21c6 (25 Jan 2020) by 杰夫·金(peff) ^{(由Junio C Hamano—gitster— in 提交341年f8a6合并，12 Feb 2020)}

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

< p > ^{报告:David Burström} < br > ^{署名:Jeff King}

允许提交28 fcc0b71a (pathspec:避免使用通配符时需要“--”，2015-05-02):

git rev-parse '*.c'

没有双破折号。

但是它用来检查通配符的规则实际上是寻找任何glob special 这是过于自由的，因为这意味着一个实际上不做任何通配符匹配的模式，如"a\b"，将被认为是一个路径规范 如果你在磁盘上有这样一个文件，这大概就是你想要的 但如果你不这样做，结果是令人困惑的:而不是说“there's no such path a\b”，我们会默默地接受它作为一个路径规范，它很可能不匹配(或至少不是你想要的) 同样地，寻找路径“a\*b”根本不会扩展搜索;它只会找到一个条目，"a*b".

此提交将规则切换为仅当glob元字符将展开搜索时才触发，这意味着这两种情况现在都将报告错误(当然，您仍然可以使用“--”消除歧义;我们只是收紧DWIM启发式)。

(德维姆:照我说的做)

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