这个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
这个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
假设我的 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
" 必须始终是用“”消除歧义--
,因为没有人会创建一个名称字面意思是星号点的文件。
Git 2.5放弃了使用通配符字符串声明用户可能打算给我们一个 pathspec 的启发式方法。
git checkout 'a*'
# same as
git checkout -- 'a*'
请参阅Duy Nguyen ( )的提交 28fcc0b(2015 年 5 月 2 日) 。(由Junio C Hamano 合并 -- --在提交 949d167中,2015 年 5 月 19 日)nguyenlocduy
gitster
pathspec
: 避免--
使用通配符时需要“”当
--
命令行中缺少“”并且命令可以同时使用 revs 和路径时,想法是如果一个参数可以被视为扩展的 SHA-1 和路径,那么“--
”是必需的,否则 git 拒绝继续。
它目前实现为:
- (1) 如果参数是 rev,那么它不能存在于工作树中
- (2) 否则,它必须存在于工作树中
- (3) 否则,“
--
”是必需的。这些规则适用于文字路径,但是当涉及到非文字路径规范时,它几乎总是要求用户添加“
--
”,因为它失败了(2)并且(1)真的很少遇到(以“*.c
”为例,(1)如果有一个名为“*.c
”的引用,则满足。此补丁通过考虑任何有效的 (
*
) 通配符路径规范“存在于工作树中”来稍微修改规则。
规则变为:
- (1) 如果 arg 是 rev,那么它必须存在于工作树中或者不是有效的通配符路径规范。
- (2) 否则,它要么存在于工作树中,要么是通配符路径规范
- (3) 否则,“
--
”是必需的。使用新规则,
--
当涉及通配符路径规范时,大多数时候不需要“”。
在 Git 2.26(2020 年第一季度)中,对区分修订和路径规范的消歧逻辑进行了调整,以便反斜杠转义的全局特殊字符不计入“通配符是路径规范”规则中。
请参阅Jeff King ( ) 的提交 39e21c6(2020 年 1 月 25 日)。(由Junio C Hamano 合并 -- --在提交 341f8a6中,2020 年 2 月 12 日)peff
gitster
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 启发式)。
请注意,我们根本没有测试28fcc0b71a中的原始功能。
所以这个补丁不仅测试了这些极端情况,还增加了对现有行为的回归测试。