By default, but it does support case sensitivity. The first thing I do on a new Mac is format with case-sensitive HFS+ and re-install OS X. I’ve been doing this for at least a decade and it’s rare that any modern programs have a problem with it (those that do can usually just be run from a case-insensitive disk image).

HFS+, like NTFS, is actually case sensitive “under the hood.” However the OS' that use them default to setting them case-insensitive. It’s not fair to pin this on the filesystem itself. I would title this “Caveats of using git on OSX”

It should be pointed out that you can fairly easily select case-sensitive formatting during OSX installation, or use a disk image formatted appropriately for your case-sensitive work.

The last time I recall this discussion going around, it was pointed out that a significant part of the OS X ecosystem (Adobe being the major offender that I recall) just doesn’t work on case-sensitive HFS+, so regrettably it’s not always as simple as making sure you only use case-sensitive filesystems.

This is one thing I don’t miss using ZFS for most places. Need a place on your file system with some funny parameters, or need to make a file system of another type inside of your existing system? Just zfs create and done. It’s wonderful.

He didn’t even mention one of the most fun situations one can end up in: at a company where I worked, one repository had readme.txt and README.TXT with different contents (done on a case-sensitive filesystem). git on case-insensitive HFS+ will always think that one of the two files has unstaged changes (depending on which of the two ended up on the file system).

This can drive people nuts who don’t know that HFS+ is case-insensitive on the Mac by default.

Another weird git behavior is that it stores some refs (in particular, some branches) in .git/refs, where they’re stored in files named after the branch name. For example, if there’s a remote branch my/fancy/branch, it might store it in .git/refs/remotes/shared/my/fancy/branch. Now, suppose someone else pushes to shared, but instead pushes my/FANCY/branch. The remote server uses a case insensitive filesystem, so it’s fine with taking both of these, but when I pull again, and see this new branch, git can have pretty strange behavior, since in case-insensitive HFS+, those directories have the same name.

This leads to worse things. Consider the case of a unicode string. HFS+ tries to decode unicode strings and will do so ambiguously. This, as far as I have been able to tell, is the reason that github doesn’t allow unicode in repository names. :-(