On Tue, Jul 04, 2017 at 10:24:30AM +0200, Ævar Arnfjörð Bjarmason wrote:
> I.e. we allow any arbitrary ref sitting in .git/, but presumably we
> could just record the original string the user provided so that this
> dies on OSX/Windows too:
>
> $ cp .git/{HEAD,Whatever}
> $ git rev-parse wHATEVER
> wHATEVER
> fatal: ambiguous argument 'wHATEVER': unknown revision or path not in the working tree.
>
> But this may be a much deeper rabbit hole than I initially thought, I
> was fishing to see if someone knew of a place in the code or WIP patch
> that dealt with these special refs, but between the low-level machinery
> & sha1_name.c (and others) there may be no easy one place to do this...
I think we talked at one point about allowing only [A-Z_] for top-level
refs. My recollection is that it generally seemed like a good idea, but
I don't think we ever had patches.
I think it would work to enforce it via check_refname_format(). That
would catch reading via dwim_ref(), which is what your example is
hitting. But it should also prevent people from writing ".git/foo" (or
worse, ".git/config") as a ref.
I do think that's the tip of the iceberg for case-sensitivity problems
with refs, though. Because packed-refs is case-sensitive, I think you
can create some pretty confusing states on case-insensitive filesystems.
For example:
http://public-inbox.org/git/20150825052123.GA523@xxxxxxxxxxxxxxxxxxxxx/
Ultimately I think the path forward is to have a ref backend that
behaves uniformly (either because it avoids the filesystem, or because
it encodes around the differences). See:
http://public-inbox.org/git/xmqqvb4udyf9.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx/
and its reply.
-Peff
