From: "Torsten Bögershausen" <tboegi@xxxxxx>
On 2015-12-21 18.37, Junio C Hamano wrote:
Duy Nguyen <pclouds@xxxxxxxxx> writes:
On Mon, Dec 21, 2015 at 6:01 PM, Philip Oakley <philipoakley@xxxxxxx>
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
--
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