Petr Baudis <pasky@xxxxxxx> writes:
> Some of the ref manipulation tools (git-for-each-ref and git-show-ref in
> particular) would not handle hidden (~ /^\./) refs.
refs.c::check_ref_format() seems to suggest that any ref whose
path component begins with a dot is invalid (since October last
year), so I am a bit surprised you are bringing this up now. Do
you know of specific examples where this is not enforced? It
could even be argued that the places in the system that allow
such a ref are buggy.
I do not recall why we decided that this particular restriction
was needed (I do understand the other three restrictions --- see
commit log of 03feddd6), although I do think this is not a
gratuitous change but comes from a list discussion. I suspect
it was to avoid confusion with ".." operator ("..." was added
much later in July this year), but it is not consistent that we
do not forbid the ones that end with a dot.
Maybe we should have found this inconsistency and added "names
that end with a dot" to the forbidden category when we
introduced the symmetric difference, but apparently nobody
noticed. Right now foo...bar is seriously ambiguous. Even
though it cannot be "foo" .. ".bar" (because ".bar" is not a
valid refname), it can be "foo." .. "bar" or "foo" ... "bar",
and worse yet spelling longhand form "refs/heads/foo." does not
help to disambiguate this.
-
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