A Simple Tweak for Making 'git rebase' Safe on OS X
git-tower.com
A Simple Tweak for Making 'git rebase' Safe on OS X
1–10 of 12 posts
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#2What 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?
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#3What 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.
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#4What 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:
_rebase = "-c core.trustctime=false rebase"
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#5Both 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?
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#6I 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.
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#7What 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?
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.
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#8I wonder if this is the same thing that causes Bitcoin-Qt to fail on modern OS X.
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#9Very 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'.
Re: A Simple Tweak for Making 'git rebase' Safe on OS X
#10This 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.