What are the consequences of the two options aside from fixing the original issue with git rebase? Should I be worried about some critical OS feature being disabled with option A or very slow git performance with option B?
I consider disabling the revisiond process a “hack“ and not really an option, as users may rely on this OS X feature. The daemon might also get re-enabled by an OS X update anytime.
This leaves you with the option to disable the core.trustctime setting, which I believe has no noticeable performance drawback for most or maybe all Git users.
If you are sensitive about the performance, perhaps a third option would be to make an alias for affected commands, especially for rebase:
The standard filesystem in Mac OS X isn't POSIX compliant and hasn't ever been (HFS+ isn't, UFS is). If you're concerned about filesystem operations working as intended in code written for things that are POSIX compliant (like Git is) don't use it.
This seems like it should be considered a bug in git. If a changed ctime would otherwise cause a failure, checking at that point whether the content actually changed shouldn't be an expensive operation, and since git does not track extended attributes or file flags (I'm guessing the problem is related to one of the two), a change in which updates ctime, such a change should not cause spurious failure.
I don't know enough about git to say whether my suggested fix is equivalent to turning trustctime off by default.
Very nice post. Just this week I had issues using 'git rebase' and eventually I gave up using this future, instead copying my old repo to a new folder and initialising the new folder as a git repo. I just assumed I did something wrong :)
Hopefully one of the solutions pointed in the article will prevent any future issues with 'git rebase'.
Both have unfortunate consequences. Surely the best thing would be to ask Apple to add an API to allow disabling revisiond for some directory, which the OSX port could use?
