Re: Possible bug with branch names and case sensitivity

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/21/2011 08:18 PM, Jay Soffian wrote:
> On Sat, Nov 19, 2011 at 3:08 PM, Gerd Knops <gerti@xxxxxxxxxx>
> wrote:
>> On Mac OS X with a case-insensitive file system (not sure if that
>> matters) git get's confused with branch names that differ only in
>> case.
> 
> This is true. The branch code assumes a case-sensitive filesystem. I 
> started working on a fix, but it was more involved than I first 
> thought it would be. See my local WIP commit below, apologies if
> gmail lines wraps it.

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.

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.

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

Michael

-- 
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]