From: Philip Oakley Date: Mon, 21 Dec 2015 19:58:53 GMT Subject: Re: [git-for-windows] Case insensitive branch names Message-ID: <93EE538CE2634272BABFCEB55C6A091E@PhilipOakley> In-Reply-To: <5678434B.5040506@web.de> From: "Torsten Bögershausen" > > On 2015-12-21 18.37, Junio C Hamano wrote: >> Duy Nguyen writes: >> >>> On Mon, Dec 21, 2015 at 6:01 PM, Philip Oakley >>> 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