Re: Possible bug with branch names and case sensitivity

From: Jay Soffian <jaysoffian@gmail.com>
Date: Nov 22, 2011, 17:31 UTC
Message-ID: <CAG+J_DxREbykWggrD49L7qvR9M36wKL7+_kOYbvcWmLBCF2Gog@mail.gmail.com>
In-Reply-To: <4ECB315F.4080701@alum.mit.edu>

On Tue, Nov 22, 2011 at 12:21 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

> Is it obvious how references *should* be handled on case-insensitive
> filesystems?  It's certainly not obvious to me (has it been discussed
> elsewhere?)  I don't think it is a good idea to "fix" this one problem
> without defining an overall policy.

Indeed, I hadn't thought this through very well at all. My initial take was just that if I were on a case-insensitive file system, I don't get to have references that differ only in case. This is of course quite short-sighted in a distributed VCS. :-(

Show 10 quoted lines

> Currently git handles references names case-sensitively and allows
> multiple reference names that differ only in case.  If this behavior is
> to be preserved on case-insensitive filesystems, then either loose
> references must be stored differently (e.g., multiple references in the
> same file) or ambiguous references need always to be packed.  Moreover,
> given a refname, we would need to be careful not to just try to open a
> file with that name and assume that it is the correct reference; rather,
> we would have to ask the filesystem for the name of the file in its
> original case and make sure that it agrees with the case of the refname
> that we seek.

I wonder what the downside would be of always using packed refs on case-insenstive file systems. This would seem analogous to how git no longer uses symlinks.

Show 20 quoted lines

> By the way, this could have ramifications for the recently-added test
> that top-level refnames should be in ALL_CAPS.
>
> If we want to consider bending git's behavior, there are a number of
> ways we could go:
>
> 1. Remain case-sensitive but prohibit refnames that differ only in case.
>
> 2. Remain case-sensitive but prohibit refnames that differ only in case
> *when running on a case-insensitive filesystem*.
>
> 3. Change the handling of refnames to be case-insensitive but
> case-preserving.
>
> The above all assumes a case-insensitive filesystem that is
> *case-preserving*.  If we want to support filesystems that do not
> preserve case, things get even more complicated.
>
> And if we want to pretend to support non-ASCII refnames, then the issue
> of encodings is another nasty can of worms...

These all seem like sub-optimal things to do if we can just always used packed refs.

j.