CODEWITHSUNDEEP
git
Number945
Number945

Reputation: 4950

git core.ignorecase = false in Mac OS X

I have made core.ignorecase=false at local and global level of configuration , yet I see strange behaviour as shown below when I do git checkout MASTER (not master).I also did git branch -v but no MASTER was shown.

git checkout master
Switched to branch 'master'

git branch
* master

git checkout MASTER
Switched to branch 'MASTER'

git branch
master

We can see there is no (*) now on master. I know Mac OS X file system is case insensitive , but then

a) What is left for significance of core.ignorecase=false of explicitly mentioning it if even after this Our OS controls it ?

b) Why is there no (*) at master branch if git is assuming MASTER and master as same ? [ EDIT : Even if you make core.ignorecase = true , we will still see this ]

Doing rev-parse , both point to same SHA1.

Upvotes: 3

Views: 6037

Answers (2)

Philip Oakley
Philip Oakley

Reputation: 14101

This is expected. Your OS / file system is case insensitive and will return a file which has alternative case within it's name. It's a one way trap door for the unwary.

Note the lack of the * against any of the listed branches when changing to the incorrectly cased branch MASTER - your OS returned the details from branch master (same filename), and checked that out. Now Git can't find MASTER in its list of available branches.

A similar issue exists on Git-for-Windows and this comes up regularly. It's not easy to resolve (code v humans).

Upvotes: 0

Dietrich Epp
Dietrich Epp

Reputation: 213837

By setting core.ignorecase=false you have misconfigured your system and you should set this to the correct value, true, if you expect Git to behave reasonably. From git-config manual:

Internal variable which enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like APFS, HFS+, FAT, NTFS, etc. For example, if a directory listing finds "makefile" when Git expects "Makefile", Git will assume it is really the same file, and continue to remember it as "Makefile".

…

Git relies on the proper configuration of this variable for your operating and file system. Modifying this value may result in unexpected behavior.

The correct value is true on macOS, unless you have specifically formatted your disk or partition as case sensitive. So you should never change this value unless the value selected by Git is incorrect. For example, the value will be incorrect if you copy a repository from a case-insensitive volume to a case-sensitive one, since Git does not probe the value after repository creation with git clone or git init.

I’m not sure what you expected to achieve by setting this variable to false, but the only thing that actually happens is that Git does not work correctly.

Note that from my tests, Git will not get the branch names correct on case insensitive filesystems if you specify branches with the wrong case. You can call this a bug in Git if you wish, but speaking from experience, getting nice behavior on case-insensitive filesystems can be difficult.

Upvotes: 7

Related Questions