Re: check-ref-format: include refs/ in the argument or to strip it?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 22, 2014, 18:37 UTC
- Message-ID
- <xmqqmwawnzfk.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20140822154151.GK20185@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 16 quoted lines
> Michael Haggerty wrote[1]: >> Jonathan Nieder wrote: > >>> The check-ref-format documentation is pretty unclear, but the >>> intent is that it would be used like >>> >>> git check-ref-format heads/master >>> >>> (see the surviving examples in contrib/examples/). That way, it can >>> enforce the rule (from git-check-ref-format(1)) >>> >>> 2. They must contain at least one /. This enforces the presence >>> of a category like heads/, tags/ etc. but the actual names >>> are not restricted. > [...] >> Thanks for the explanation and the pointer.
I wanted to follow this discussion, especially the ellided [...] "pointer", but had a hart time finding what "pointer" was.
Anyway, the true origin of ONELEVEL as far as I recall was to give us a way to say "in this code path, we also expect to be fed HEAD, ORIG_HEAD, etc., so please do not subject us to the 'at least one slash' rule.", implication of which is that the 'at least one slash' rule was to expect things are 'refs/<anything>' so there will be at least one. Even back then, that <anything> alone had at least one slash (e.g. heads/master), but the intention was *never* that we would forbid <anything> that does not have a slash by feeding <anything> part alone to check-ref-format, i.e. things like "refs/stash" were designed to be allowed.
That the function does not reject what does not begin with "refs/" when ONELEVEL is not in effect is just being loose.