Heh, then I'll forward my response and we are even ;-) ---------- Forwarded message ---------- From: Junio C Hamano <gitster@xxxxxxxxx> 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@xxxxxxxxxxxx> Michael Haggerty <mhagger@xxxxxxxxxxxx> 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? > 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.
