On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller <jacob.kel...@gmail.com> wrote: > > On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen <pclo...@gmail.com> wrote: > > Even with a new ref storage, I'm pretty sure pseudo refs like HEAD, > > FETCH_HEAD... will forever be backed by filesystem. HEAD for example > > is part of the repository signature and must exist as a file. We could > > also lookup pseudo refs with readdir() instead of lstat(). On > > case-preserving-and-insensitive filesystems, we can reject "head" this > > way. But that comes with a high cost. > > -- > > Duy > > Once other refs are backed by something that doesn't depend on > filesystem case sensitivity, you could enforce that we only accept > call-caps HEAD as a psuedo ref, and always look up other spellings in > the other refs backend, though, right?
Hmm.. yes. I don't know off hand if we have any pseudo refs in lowercase. Unlikely so yes this should work. > So, yea the actual file may not > be case sensitive, but we would never create refs/head anymore for any > reason, so there would be no ambiguity if reading the refs/head vs > refs/HEAD on a case insensitive file system, since refs/head would no > longer be a legitimate ref stored as a file if you used a different > refs backend. > > Basically, we'd be looking up HEAD by checking the file, but we'd stop > looking up head, hEAd, etc in the files, and instead use whatever > other refs backend for non-pseudo refs. Thus, it wouldn't matter, > since we'd never actually lookup the other spellings of HEAD as a > file. Wouldn't that solve the ambiguity, at least once a repository > has fully switched to some alternative refs backend for non-pseudo > refs? (Unless I mis-understand and refs/head could be an added pseudo > ref?) No I think "pseudo refs" are those outside "refs" directory only. So "refs/head" would be a "normal" ref. > Jake -- Duy
