Re: BUG FOLLOWUP: Case insensitivity in worktrees

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 24, 2020, 19:36 UTC
Message-ID: <xmqq7dusn1su.fsf@gitster.c.googlers.com>
In-Reply-To: <02819EF1-CCA7-4A0F-9497-F6A52E6CBF30@strongestfamilies.com>

Casey Meijer <cmeijer@strongestfamilies.com> writes:

Show 9 quoted lines

> 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.