Re: Branch Name Case Sensitivity

From: Karsten Blees <karsten.blees@gmail.com>
Date: Feb 28, 2014, 13:56 UTC
Message-ID: <5310959D.709@gmail.com>
In-Reply-To: <53102FB0.6040603@viscovery.net>

Am 28.02.2014 07:41, schrieb Johannes Sixt:

Show 7 quoted lines

> Am 2/28/2014 0:38, schrieb Lee Hopkins:
>>> If I understand the issue correctly, the problem is that packed-refs
>>> are always case-sensitive, even if core.ignorecase=true. OTOH,
> 
> core.ignorecase is intended to affect filenames of the worktree, not
> anything else, BTW.
>

from git-config(1): "enables various workarounds to enable git to work better on filesystems that are not case sensitive"

It says nothing about work-tree only, so I'd expect it to apply to all git components that store potentially case-sensitive information in file names.

...it also says "better", not "flawlessly" :-)

Show 16 quoted lines

>>> checking / updating _unpacked_ refs on a case-insensitive file system
>>> is naturally case-insensitive. So wouldn't it be a better workaround
>>> to disallow packed refs (i.e. 'git config gc.packrefs false')?
>>
>> You are correct, the issue boils down to mixing the usage of 
>> packed-refs and loose refs on case insensitive file systems. So either 
>> always using packed-refs or always using loose refs would take care of 
>> the problem. Based Michael Haggerty's response, it seems that always 
>> using loose refs would be a better workaround.
> 
> So, everybody on a case-insensitive file system should pay the price even
> if they do not need the "feature"? No way.
> 
> If you are on a case-insensitive filesystem, or work on a cross-platform
> project, ensure that you avoid ambiguous refs. Problem solved.
>

So its OK to lose data if you accidentally use an ambiguous ref? I cannot believe you actually meant that.

IMO the proper solution is to teach packed-refs about core.ignorecase. Until that happens, disabling gc.packrefs seems to be a valid workaround for people who have that problem.