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

From: Philip Oakley <philipoakley@iee.org>
Date: Dec 21, 2015, 19:58 UTC
Message-ID: <93EE538CE2634272BABFCEB55C6A091E@PhilipOakley>
In-Reply-To: <5678434B.5040506@web.de>

From: "Torsten Bögershausen" <tboegi@web.de>

Show 22 quoted lines

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

Show 8 quoted lines

>>
>> 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;-)

Show 9 quoted lines

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