On Dec 4, 2007, at 10:40 AM, Johannes Sixt wrote:
Junio C Hamano schrieb:
* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
+ refactor fetch's ref matching to use refname_match()
+ push: use same rules as git-rev-parse to resolve refspecs
+ add refname_match()
+ push: support pushing HEAD to real branch name
The last one changes the semantics to somewhat less safe:
* We did not allow fetching outside refs/ (except HEAD), but
now we
allow any random string.
* We used to restrict fetching names that do not begin with
refs/ to
heads, tags and remotes, but now the code grabs anything
underneath
refs/.
which could invite mistakes by letting typos slip through, but I
won't
be a good judge, as I probably "fetch" much less often than other
people
do and these may be non issues in the real-world usecases. It
could be
that I am worried too much needlessly. If anybody who is following
'next' has been bitten by the change, please speak up. Otherwise
this
will go in soon.
Forks on repo.or.cz use the namespace refs/forkee that lists
everything that the forkee has below refs/. So this change might
indeed be annoying. (But I'm not using next, so I can't tell, yet.)
But only if you accidentally wrote
git fetch forkee/heads/something
instead of
git fetch heads/something
which I don't think is a very likely typo.
With the last change, fetch still requires a match of the full
refspec created by prefixing a short refspec with "refs/".
Different from the old behaviour, it does no longer verify
that the short refspec from the command line starts with
heads, tags, or remotes. However, it does _not_ recurse
into "sub-directories" to find a matching ref. It won't
recurse into forkee, unless you explicitly tell fetch to look
in forkee. With the old implementation you'd have to say
"refs/forkee/heads/something", while the new implementation
would also accept "forkee/heads/something".
Steffen
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
