A Simple Tweak for Making 'git rebase' Safe on OS X

Since OS X 10.7 Lion and the introduction of the Auto-Save and Versions features (which automatically records the history of files), some Git commands like "rebase" might fail on Mac OS systems.

When performing a large rebase with several commits and many changed files, the rebase process can randomly abort, stating that there are uncommitted changes and rebase cannot continue. However, a "git status" does not report any changes.

When aborting the rebase process and re-running it, it will again randomly abort at any commit until (after several retries) it may or may not finally succeed.

This can lead to a scenario where a commit is accidentally skipped by the developer if he's not aware of the issue and continues the rebase.
The problem has been tracked down to the revisiond daemon of the OS X Versions feature, which detects file changes and seems to somehow alter the file system info of the file, causing a rebase step to fail as it then detects changes.

Good News

Now, finally, comes the good news: there are solutions to this problem!

(a) Disabling "revisiond"
One option is to permanently disable the revisiond daemon.

(b) Setting "core.trustctime" to False
Another solution (see this discussion on StackOverflow) uses the Git config key "core.trustctime":

core.trustctime
If false, the ctime differences between the index and the working tree are ignored; useful when the inode change time is regularly modified by something outside Git (file system crawlers and some backup systems). See git-update-index(1). True by default.

Setting it globally to "false" will enforce the rebase process to stop relying on the file system info alone:

git config --global core.trustctime false

More Good News - For Tower Users

If you're using Tower, you can rest assured: Tower will take care of this problem. In upcoming versions, we will always pass this config option as an additional option for affected commands. E.g.:

git -c core.trustctime=false rebase master