Junio C Hamano <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
