Non case-sensitive Mac OS Extended formatting colliding with git clone

If you use Mac OS for development and have ever experienced that cloning a GIT repository produces instant non staged changes for commit then this is your post. Here I will explain the underlying problem for this GIT weird behaviour and propose 2 solutions: (i) lazy i-don’t-want-to-format-my-mac, and (ii) I want to do things right. So, let’s get started.

I was cloning the linux kernel branch of Xilinx (it does not really matter which branch, this problem appears in all kernel repositories) when I experienced that a set of files appeared as modified right after cloning. To be more specific, I received the message Changes not staged for commit: + a bunch of files. It did not matter how many times I cloned or which clone options I used, the problem persisted.

Screen Shot 2013-09-04 at 17.13.39

Funny though, when cloning the same repository in Linux (Ubuntu 12.04 LTS) the files did not appear unstaged.

The problem – to my utter surprise – is that the default formatting of HFS+ (e.i., the file system used by Mac OS, also known as Mac OS Extended) is not case-sensitive. In the cloning process some of the files in uppercase overwrite the files with the same name in lowercase (and vice versa) producing the unstaged changes. What to do? you have 2 main options (at least that I thought of):

Format your HFS+ to be case-sensitive

HFS+ has four variations:

  • Mac OS Extended
  • Mac OS Extended (Journaled)
  • Mac OS Extended (Case-sensitive)
  • Mac OS Extended (Case-sensitive, Journaled)
  • Mac OS Extended ( Journaled, Encrypted) *
  • Mac OS Extended (Case-sensitive, Journaled, Encrypted) *

* Mac OS Lion (maybe in the future too)

You can easily check the variation of your file system by typing:

$ diskutil info /

The output should be something like this:

File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)
Journal: Journal size 24576 KB at offset 0x774000
Owners: Enabled

Once you have confirmed that your file system is not case sensitive, then proceed to update you backup, commit all your changes and format to the case-sensitive variation of HFS+ you like the most. It is important to mention here that a Time Machine backup will probably not do the work. I explain: Time Machine is a backup of the whole system and therefore a restore from Time Machine will probably overwrite the new format (case-sensitive in this case). It would be better to do an old-fashioned backup and then start a new Time Machine backup from scratch.

After that you will not experience any more problems regarding unstaged changes after cloning a fresh repository (I know this is a strong statement, but unstaged commits after cloning makes just no sense in terms of GIT and should only occur in the event of an unfulfilled GIT assumption, as it is a non case-sensitive file system).

Lazy approach

If you do not want/cannot/do not have time/etc to format, you can always install a virtual machine with a linux distribution on it and create a soft link (ln -s) to your work directory from inside the virtual machine. This is of course assuming that you want to continue developing from Mac OS. You can always move completely to the virtual machine. (Please not that sharing folders from a guest OS to a virtual machine normally requires installing a set of extra tools in you virtual machine (e.g., Guest Additions in Virtual Box, Parallels Tools in Parallels, etc)).

While this approach might seem to save time, it actually slows down writes and reads since they are pipelined program > virtual FS > HFS+. This can slow down the kernel compilation by several seconds.

Unless you are in a hurry and do not plan to do a lot of compilation, I would strongly recommend formatting to a case-sensitive HFS+. Moreover, the flexibility of using a case-sensitive file system is worth the time. It will allow you (for example) to avoid collisions when installing software originally conceived for linux/unix systems.

Enjoy 🙂


2 thoughts on “Non case-sensitive Mac OS Extended formatting colliding with git clone

  1. I just realized that comments where disabled when James Sanderson wrote me an email describing a faster way to solve this problem without the need of VMs. I copy-paste:

    “I just got in touch to mention that I know of an even lazier approach that, as a bonus, is a lot faster than using a virtual machine: create and mount a disk image!

    It clicked straight away after reading your blog post that that would be the fastest way to fix my problem, as I’d previously followed the instructions here: on doing just that (although this time around, I confess, I used the Disk Utility GUI instead).”

    Thanks for the comment James!


  2. Pingback: Parallels 9 for Mac improving guest – host communication | My Cellar Door

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s