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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2017, 00:49 UTC
Message-ID: <CAPc5daXj4sBuWP0r6t0nArXt1DJW+9byT49M_g8LcjrqBMJnRg@mail.gmail.com>
In-Reply-To: <xmqqa84c6v41.fsf@gitster.mtv.corp.google.com>

Heh, then I'll forward my response and we are even ;-)

---------- Forwarded message ----------
From: Junio C Hamano <gitster@pobox.com>
Date: Mon, Jul 10, 2017 at 10:48 AM
Subject: Re: Should "head" also work for "HEAD" on case-insensitive FS?
To: Michael Haggerty <mhagger@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 6 quoted lines

> 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?

> But...since we are talking about introducing a new loose reference
> filename encoding, ...

Yes, but that is an encoding detail I do not have to get involved and folks with platform needs can add more on top---we need to make sure that the places that encode and decode are identified in the code first, and the things like "FOO is encoded upon writing because files-backend is asked to write it, but not decoded because refs.c thinks it is pseudo-ref and does not give a say to files-backend" shouldn't be happening before we can start working on the details of the encoding. Making a conscious decision that pseudo-refs are left as-is is OK, but we need to see both reading and writing side following the same codepath to make that decision, which does not seem to be the case in the current code.