Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > 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. -- 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