HFS+ is not case sensitive.
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).
Cough: Adobe apps, last I checked.
Most apps with WIndows as lead platform, e.g. games. (Eve Online is one I am aware of)
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.
use a disk image formatted appropriately for your case-sensitive work
I believe that’s the solution the post proposes at the end.
Yep, that’s what I ended up doing.
@brycied00d Fair point. Thanks for the clarification.
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.
git on case-insensitive HFS+ will always think that one of the two files has unstaged changes
Oooh that’s fun indeed! I’ll try this locally over the weekend and probably add it to the post.
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.
I have to admit, I didn’t know this about HFS+. Does anyone have a guide/walk-through/advice on reformatting macs to be case sensitive??
Create a new partition that is case sensitive (shrinking your existing one) and mount it at ~/src.
Do not make / case sensitive if you care about most things continuing to work well (steam / adobe suite / for awhile chrome didn’t handle it, that I know of)
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. :-(