Re: [git-for-windows] Case insensitive branch names

["Philip Oakley" <philipoakley@iee.org>]

From: "Torsten Bögershausen" <tboegi@web.de>
>
> On 2015-12-21 18.37, Junio C Hamano wrote:
>> Duy Nguyen <pclouds@gmail.com> writes:
>>
>>> On Mon, Dec 21, 2015 at 6:01 PM, Philip Oakley <philipoakley@iee.org> 
>>> wrote:
>>>> On the Git User's list, Diego J. reported that:
>>>>
>>>> 'When I "checkout" a branch using different Upper Case/Lower Case than 
>>>> the
>>>> original, the branch doesn't show in "git branch [--list]"' [1]
>>>>
>>>> While case sensitivity for filenames is a common issue on Windows and 
>>>> the
>>>> like, I haven't seen any discussion regarding ref name sensitivity - 
>>>> any
>>>> pointers to past discussions?
>>> Multiple ref backend [1] should solve this.
>> Yup, I had the same reaction.  Instead of restricting the namespace
>> of branches even on systems that do not have this problem, use a ref
>> backend that is not limited by the underlying filesystem.  A much
>> better solution.

My thought was more that on a case preserving FS we (that FS Git 
implementation) might warn if they have ended up not on a valid branch name. 
It felt wrong that the checkout reported success.

>>
>> In addition to the LMDB backend, it might not be a bad idea to add
>> another filesystem-based backend that encodes the refnames safely on
>> case insensitive or case destroying filesystem.  That way, those who
>> do not want an extra dependency but do want case sensitive refnames
>> would have an option, and having two non-default backends with quite
>> different semantics may be a good way to ensure that the API for
>> refs backend is kept sane.

A suitable case sensitive, case preserving backend would solve it for those 
using it, which will be a help. Though those that don't will still need to 
be careful.

>
> This has been reported (probably a couple of times),
> one copy I have here was under "Branch Name Case Sensitivity"
> around Feb/March 2014.

Found the thread 
http://thread.gmane.org/gmane.comp.version-control.git/242768/focus=242846
though I try to avoid having a 'don't do that' response for some of these 
potentially hazardous cases (though the cost benefit may not justify it;-)

>
> The lstat() in refs.c can not be fixed, as the underlying OS/FS thinks
> that lstat("nocase") == lstat("NoCase") and
> open("nocase") == NoCase").
>
> The the "real name" will not be detected, unless somebody does
> opendir(), readdir() and closedir().
> This is expensive (in terms of execution time), and nobody
> has tried to do something.

That's probably a key bit of info I didn't know - that the true file name 
can't be known without that overhead. Various stackoverflow Q&As [1] show 
that others have also had some difficulties...

>
> One cheap solution would be to run "git pack-refs" internally,
> either from C-code inside Git itself, or from a script.
>

--
Philip
[1] Windows methods of getting true file name (allegedly)
http://stackoverflow.com/questions/4763117/how-can-i-obtain-the-case-sensitive-path-on-windows/4763137#4763137
http://stackoverflow.com/questions/478826/c-sharp-filepath-recasing/479198#479198
http://stackoverflow.com/questions/74451/getting-actual-file-name-with-proper-casing-on-windows