[PATCH 0/4] exact ref-matching for fetch-pack

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