Jeff King <p...@peff.net> writes:
> Then we ask fetch_refs_via_pack to get the actual objects for us. And
> it checks our refs again, with this call chain:
> Here, the code looks like this:
> if (!memcmp(ref->name, "refs/", 5) &&
> check_refname_format(ref->name + 5, 0))
> ; /* trash */
I think this should feed ref->name, not ref->name + 5; an obvious
alternative would be to use REFNAME_ALLOW_ONELEVEL; you are also
right that && is probably a misspelt ||; this is about protecting
ourselves from creating garbage in our ref namespace, so accepting
anything outside refs/ makes little sense.
> It's really not clear to me what the check in filter_refs was trying to
> do. It dates all the way back to 1baaae5 (Make maximal use of the remote
> refs, 2005-10-28), but there is not much explanation. I haven't dug into
> the list around that time to see if there's any discussion.
I think the "funny refs" the log message talks about is about
filtering "we know we can reach these objects via our alternates,
but these are not refs we actually have".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html