看一下这些示例显示refspecs可以过滤目录/命名空间,如下所示:
+refs/heads/qa/*:refs/remotes/origin/qa/*
但是我正在尝试优化获取和我正在使用的repo具有如下命名的分支:
release-6.0.0
当尝试过滤这些时,我得到:
fatal: Invalid refspec '+refs/heads/release*:refs/remotes/upstream/release*'
有没有办法在提取中过滤这些或我需要获取所有远程头？
Git 2.6+(2015年第3季度)将允许这种refspec!
请参阅Jacob Keller()提交cd377f4,提交53a8555(2015年7月22日).(由Junio C Hamano合并- -在提交8d3981c,2015年8月3日)jacob-keller
gitster
refs:放宽对通配符"*"refspecs的限制通过允许
*在组件中具有" "而不是仅作为整个组件的模式来放宽对refspecs的限制.删除逻辑以接受单个"
*"作为整个组件check_refname_format(),并在check_refname_component()中实现该逻辑的扩展形式.
将指针传递给后者的flags参数,因为它必须REFNAME_REFSPEC_PATTERN在看到"*" 时清除位.示教
check_refname_component()函数只允许在标志中设置星号"*"REFNAME_REFSPEC_PATTERN,并在看到"*"后删除该位,以确保refspec的一侧最多包含一个星号.这将允许我们接受refspecs,如
for/bar*:foo/baz*.
之前运行的任何refspec将继续使用新逻辑运行.
原始答案(2013)
这似乎不可能,因为该限制有助于完成refs匹配remote.c.
这可以追溯到Git 1.5.6.5(2008年8月)并提交b2a5627(Daniel Barkalow),它强制执行"通配符refspec必须以斜线和星号结尾"的规则:
通配符的Refspec内部解析成的Refspec结构
src和dst字符串.
代码的许多部分假设/*在将通配符模式与我们在远程处看到的实际引用匹配时不包括尾部" ".
这意味着我们不仅要确保前缀匹配,还要确保匹配的部分后面有斜杠.但是扫描结果
ls-remote并找到匹配引用的代码路径忘记检查"匹配部分必须后跟斜杠"规则.
这导致来自远程端的"refs/heads/b1"错误地匹配refs/heads/b/*:refs/remotes/b/*"refspec "的源端.更糟糕的是,
git-clonerefspec 在内部由" " 制作,并且用于实现"git-fetch --tags" 的硬编码的预制refspec 违反了这个"解析的widcard refspec并不以斜线结束"规则; 只需添加"匹配部分必须后跟斜杠"规则,然后就会破坏使用这些refspecs的代码路径.此提交将规则更改为需要使用尾部斜杠来解析通配符refspecs.
IOW,"refs/heads/b/*:refs/remotes/b/*"被解析为src = "refs/heads/b/"和dst = "refs/remotes/b/".
这允许我们简化匹配逻辑,因为我们只需要prefixcmp()注意"refs/heads/b/one"匹配而"refs/heads/b1"不需要.
该OP蒙古尔丁指出了提交46220ca(DIFF)为这条规则的(GIT 1.5.5,2007年4月)的由来
根据我的建议,我们在之前的提交ef00d15(收紧refspec处理,2008-03-17)中收紧了refspec验证代码,但这个建议被误导了,它打破了这种用法:
$ git push origin HEAD~12:master
push refspecs和fetch refspecs的语法类似,因为它们都是冒号分隔的LHS和RHS(可能以
+强制为前缀),但相似性在那里结束.
例如,push refspec中的LHS可以是在运行时评估为有效对象名称的任何内容(冒号和RHS丢失时除外,或者它是一个glob),而在fetch refspec中它必须是一个有效的refname.
要正确验证它们,调用者需要能够说出它们是哪种refspec.
保持单个界面不能分辨它正在处理哪种类型并要求它表现得合理是不合理的.此提交将两者的解析分离为不同的函数,并澄清代码以实现正确的解析(即分成两部分,确保两边都是通配符或两边都不是).