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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

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

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]