I was passed a bug report of clone failing on a repo with an oddly named
ref in it: "refs/for/refs/heads/master". This is probably an error
somebody made while pushing and should simply be deleted. However, it's
curious that "clone" would fail on this, since it should be ignoring
everything outside the "refs/heads/*" refspec.
It turns out that during the fetch-pack phase, we accidentally ask for
the sha1 of "refs/for/refs/heads/master" instead of that of
"refs/heads/master". This can cause "clone" to fail, as we may not have
asked for the object pointed to by "refs/heads/master" at all. This
behavior is due to some questionable suffix-matching deep inside
fetch-pack. The code in question dates back to the beginning of git; I
think it simply hasn't triggered much because the refname you need to
have is so specific (you must be asking to fetch a ref "refs/X", have
"refs/Y/X" on the remote, and "Y" must come alphabetically before "X",
since we match refs in alphabetical order).
As I said, this is probably just a silly one-off error. But I could
imagine this happening legitimately. Here are two possible scenarios:
1. You are mirroring some meta-information about your refs in a
parallel namespace. E.g., "refs/descriptions/refs/heads/master"
contains information about "refs/heads/master".
2. One of the things we've discussed for future git is mirroring the
remote ref namespaces more literally. E.g., having something like
"refs/remotes/origin/refs/heads/master". That won't actually
trigger this bug because "heads" is alphabetically before
"remotes". But "tags", for example, is not.
This could possibly be considered a behavior regression for users of the
fetch-pack command line. See patches 2 and 3 for details.
[1/4]: drop "match" parameter from get_remote_heads
[2/4]: t5500: give fully-qualified refs to fetch-pack
[3/4]: fetch-pack: match refs exactly
[4/4]: connect.c: drop path_match function
-Peff
--
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