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.

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 🙂

–javier