Re: BUG FOLLOWUP: Case insensitivity in worktrees

Casey Meijer [off-list ref] writes:

Sorry I got mixed up,, that last message should have been
addressed to Junio.

My apologies. 

To put it very simply, I'm asking that git respect the separation
of concerns between itself and its storage engine (regardless of
whether that's pluggable, or just the current filesystem, which I
guess is technically pluggable, lol).

If "git" is told to store ref 'foo' pointing at object X and then
ref 'Foo' pointing at object Y by the end user, after claiming to
have done these two operations, if it is then asked about the value
of 'foo', it must say that 'foo' points at object X and not Y.  If a
ref backend is based on case insensitive filesystem, there are only
two options available.  (1) ignore case and violate the expectation
of end user. (2) come up with a way to "defeat" the limitation of
case insensitivity imposed by the filesystem (e.g. your ref backend
implementation _could_ URLencode/decode the ref before using it as a
filename on such a filesystem).  

Doing (2) would be transparent to the rest of Git (i.e. the rest of
Git does not have to care that each ref is stored in a file, whose
filename is encoded version of the refname) and gives us a good
separation of concerns between it and the storage backend.  Those
who ported Git to case insensitive filesystems didn't and chose (1).

As (1) violates end-user expectation, I would think it is fair to
declare it a bug.