Re: Bug report: stash in upstream caused remote fetch to fail

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 7, 2014, 03:19 UTC
Message-ID: <7vtxdg1nsg.fsf@alter.siamese.dyndns.org>
In-Reply-To: <xmqq4n5ghf0z.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

>> 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".

Actually, I think the above recollection of mine was completely bogus. The && is there because we do allow things like "HEAD" (they are the funny ones) as well as things inside refs/, and the latter is the only thing we had a check-ref-format to dictate the format when the code was written.

I do not mind tightening things a bit (e.g. outside refs/, only allow HEAD and nothing else). A good first step might be to enforce allow-onelevel outside refs/ (so that we can allow "HEAD") and for those inside refs/ check without allow-onelevel but without skipping the prefix.

It is a separate story if it makes much sense to allow fetching refs/stash or ignoring when running "git clone". Operationally, I think it makes more sense to ignore refs/stash, not because it is a one-level name, but because what a stash is.