A Simple Tweak for Making 'git rebase' Safe on OS X | Hacker News Reader

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

git-tower.com

39 pointsalxndrr10 comments

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?

Option A will disable the same-disk Time Machine snapshots feature, while option B will slow down git.

Personally, I've never encountered this issue and I rebase frequently.

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:

_rebase = "-c core.trustctime=false 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.

> checking at that point whether the content actually changed shouldn't be an expensive operation

This is only true if you have very little "content".

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'.

I think I have run into this with Keynote (esp. the latest version). I had some notes on dealing with rebase/merges conflicts here http://www.win-vector.com/blog/2013/10/resolving-git-pseudo-... , but this is another wrinkle.

I wonder if this is the same thing that causes Bitcoin-Qt to fail on modern OS X.

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?

Reply on news.ycombinator.com