Re: Should "head" also work for "HEAD" on case-insensitive FS?

From: Jeff King <peff@peff.net>
Date: Jul 5, 2017, 08:36 UTC
Message-ID: <20170705083611.jgxbp4sqogicfwdb@sigill.intra.peff.net>
In-Reply-To: <87van8boe9.fsf@gmail.com>

On Tue, Jul 04, 2017 at 10:24:30AM +0200, Ævar Arnfjörð Bjarmason wrote:

Show 13 quoted lines

> 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@sigill.intra.peff.net/

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@gitster.mtv.corp.google.com/

and its reply.

-Peff