Thank you, I get your point. Well this proposed solution will exceed my current knowledge of the git code at this point. (Which is basically null because I've never built it before) > On 11 Mar 2016, at 5:23 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> It is a possibility to teach the files backend of refs API that some >> filesystems are case insensitive and do something special about them, >> but I think in the longer term a more productive solution would be >> to use the upcoming "pluggable ref backend" subsystem and either >> >> - use a backend that is not the "files" backend (e.g. lmdb backend, >> or the tree-object based backend); >> >> - add a variant of "files" backend but encodes the refnames in a >> way that is safe on case insensitive filesystems. > > A typofix s/but encodes/that encodes/ is needed to make this > sentence make any sense. Sorry for a typo. > > Just to elaborate a bit more, here is what I mean: > > - Thanks to recent work by David, Ronnie and Michael, we eradicated > most if not all code that assume that the result of checking > "test -f .git/refs/heads/foo" tells us if a branch 'foo' exists > [*1*]. They all go through the API designed to allow different > backends to access refs. > > - The traditional code that implemented 'foo' branch as writing a > file '.git/refs/heads/foo' has been moved to a "files" backend. > When used on a platform with case insensitive filesystem, it can > answer "it exists" when asked about a branch 'Foo' (notice the > case difference). > > - We could add a new backend that is still based largely on the > existing "files" backend code, but stores 'foo' branch as a file > ".git/refs/6865616473/666f6f" while storing another branch 'Foo' > as ".git/refs/6865616473/466f6f" (I just used byte values in hex > in this example, but of course you can use a more efficient and > mostly human readable representations). > > That way, even on a platform with case insensitive filesystem, you > do not have to worry about getting confused by the filesystem when > you have 'foo' and 'Foo' branches. > > > [Footnote] > > *1* This is not strictly true even in the pre-pluggable ref backend > world, as your refs may appear in the packed-refs file, but this > detail does not matter in the larger picture. > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html