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

From: Jeff King <peff@peff.net>
Date: Jul 27, 2017, 14:35 UTC
Message-ID: <20170727143507.bezad7dnthx4nqtc@sigill.intra.peff.net>
In-Reply-To: <CAPc5daXj4sBuWP0r6t0nArXt1DJW+9byT49M_g8LcjrqBMJnRg@mail.gmail.com>

On Wed, Jul 26, 2017 at 05:49:47PM -0700, Junio C Hamano wrote:

Show 20 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
> > I think the most natural thing would be to use different encoding
> > rules for pseudo-refs (references like "HEAD" and "FETCH_HEAD") and
> > for other references (those starting with "refs/").
> >
> > Pseudo-refs (with the partial exception of "HEAD") are quite peculiar
> > beasts....
> 
> I agree with the reasoning, but what I am worried about is that
> their handling in the existing refs.c code may be leaky and/or
> inconsistent.
> 
> What I saw was that a test have ended up with .git/%46%4F%4F when it
> was told to create a ref "FOO" (which indicates that "FOO" was
> passed to the files backend), which later failed to read it back
> because the pseudo_ref handling refs.c wanted to see ".git/FOO" on
> the reading side.
> 
> Perhaps it is only a bug in t/t1405-main-ref-store.sh?

An interesting related issue for pseudo-refs: if you encode HEAD as .git/%48%45%41%44, how will we recognize that directory as a git repository? Detecting (and doing a sanity check on) "HEAD" is one of the key mechanisms for deciding whether we are in a git repository.

Obviously an older version of git that doesn't know about the new encoding scheme wouldn't work on this repository anyway. But:

  1. It should say "this is a git repo, but not a vintage I understand".
     Not "this isn't a git repo, I'll keep looking".

  2. How does a git version of the correct vintage decide "this is a git
     repo, so I'll check its config for extensions.refBackend, and a-ha,
     they _do_ have a HEAD". There's a chicken-and-egg problem.

Obviously for (2) we could teach that mechanism to look for the encoded HEAD file, too. But this is just one backend. What about a reftable or other non-filesystem store that keeps "HEAD" inside a file?

I kind of wonder if more exotic ref storage backends should always just place a dummy "HEAD" file that is enough to bootstrap the "this is a git repo" process (for both new and old versions).

This is orthogonal to the rest of the pseudo-refs discussion, but just something I thought of while reading the thread.

-Peff