假设我的Git存储库中有一个名为/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-checkout:参数消歧中有记录。

假设我的Git存储库中有一个名为/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-checkout:参数消歧中有记录。

注意，从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*'

参见Duy Nguyen (nguyenlocduy)的commit 28fcc0b(2015年5月2日)。 (由Junio C Hamano合并- gitster -在提交949d167, 2015年5月19日)

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.

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

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

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).

(DWIM:照我说的做)

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

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