git - 是否可以在目录命名空间以外的地方使用 refspec 中的过滤器？

Question

查看this示例显示 refspecs 可以过滤目录/命名空间，如下所示:


+refs/heads/qa/*:refs/remotes/origin/qa/*


但是我正在尝试优化提取，而我正在使用的 repo 协议(protocol)有这样命名的分支:
版本 6.0.0
当尝试过滤这些时，我得到:


致命:无效的 refspec '+refs/heads/release*:refs/remotes/upstream/release*'
有什么方法可以在获取中过滤这些，还是我需要获取所有远程头？

Answer 1

Git 2.6+(2015 年第 3 季度)将允许这种 refspec!

参见 commit cd377f4 , commit 53a8555 (2015 年 7 月 22 日)作者 Jacob Keller (jacob-keller) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit 8d3981c ，2015 年 8 月 3 日)}

refs: loosen restriction on wildcard "*" refspecs

Loosen restrictions on refspecs by allowing patterns that have a "*" within a component instead of only as the whole component.

Remove the logic to accept a single "*" as a whole component from check_refname_format(), and implement an extended form of that logic in check_refname_component().
Pass the pointer to the flags argument to the latter, as it has to clear REFNAME_REFSPEC_PATTERN bit when it sees "*".

Teach check_refname_component() function to allow an asterisk "*" only when REFNAME_REFSPEC_PATTERN is set in the flags, and drop the bit after seeing a "*", to ensure that one side of a refspec contains at most one asterisk.

This will allow us to accept refspecs such as for/bar*:foo/baz*.
Any refspec which functioned before shall continue functioning with the new logic.

---

原始答案(2013 年)

这似乎是不可能的，因为这种限制促进了 remote.c 完成的 refs 匹配。 .

这可以追溯到 Git 1.5.6.5(2008 年 8 月)和 commit b2a5627 ( Daniel Barkalow ) 强制执行“通配符 refspec 必须以斜杠和星号结尾”的规则:

A wildcard refspec is internally parsed into a refspec structure with src and dst strings.
Many parts of the code assumed that these do not include the trailing "/*" when matching the wildcard pattern with an actual ref we see at the remote.
What this meant was that we needed to make sure not just that the prefix matched, and also that a slash followed the part that matched.

But a codepath that scans the result from ls-remote and finds matching refs forgot to check the "matching part must be followed by a slash" rule.
This resulted in "refs/heads/b1" from the remote side to mistakenly match the source side of "refs/heads/b/*:refs/remotes/b/*" refspec.

Worse, the refspec crafted internally by "git-clone", and a hardcoded preparsed refspec that is used to implement "git-fetch --tags", violated this "parsed widcard refspec does not end with slash" rule; simply adding the "matching part must be followed by a slash" rule then would have broken codepaths that use these refspecs.

This commit changes the rule to require a trailing slash to parsed wildcard refspecs.
IOW, "refs/heads/b/*:refs/remotes/b/*" is parsed as src = "refs/heads/b/" and dst = "refs/remotes/b/".
This allows us to simplify the matching logic because we only need to do a prefixcmp() to notice "refs/heads/b/one" matches and "refs/heads/b1" does not.

---

OP Monte Goulding指出 commit 46220ca ( diff ) 作为这条规则的起源(Git 1.5.5，2007 年 4 月)

We tightened the refspec validation code in an earlier commit ef00d15 (Tighten refspec processing, 2008-03-17) per my suggestion, but the suggestion was misguided to begin with and it broke this usage:

$ git push origin HEAD~12:master

The syntax of push refspecs and fetch refspecs are similar in that they are both colon separated LHS and RHS (possibly prefixed with a + to force), but the similarity ends there.
For example, LHS in a push refspec can be anything that evaluates to a valid object name at runtime (except when colon and RHS is missing, or it is a glob), while it must be a valid-looking refname in a fetch refspec.
To validate them correctly, the caller needs to be able to say which kind of refspecs they are.
It is unreasonable to keep a single interface that cannot tell which kind it is dealing with, and ask it to behave sensibly.

This commit separates the parsing of the two into different functions, and clarifies the code to implement the parsing proper (i.e. splitting into two parts, making sure both sides are wildcard or neither side is).