Re: BUG FOLLOWUP: Case insensitivity in worktrees

[Junio C Hamano <gitster@pobox.com>]

Casey Meijer <cmeijer@strongestfamilies.com> 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.