Jonathan Nieder <jrnie...@gmail.com> writes:
> Michael Haggerty wrote:
>> 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.
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