> [FSMonitor] is currently available on macOS and Windows.
Are there any other git features with this limitation? Wild to me that we're here.
Thankfully the article covers the semi-longstanding "hooks" that existing (& very high performance) tools like Watchman (which are cross platform) can use.
Great in depth read. Good stuff! From the 2.37 release[1].
I've been wondering about why there was no linux support, and found an e-mail from the author of the subcommand (as well as the github.blog post) explaining the situation.
Apparently an older implementation using inotify was dropped because inotify does not work recursively, so you would have to do an inotify call for all directories of the hierarchy which is obviously very inefficient. There are system wide limits in the number of directories you can listen to, and even if you increase the limit you would probably cause a lot of overhead.
Newer linuxes support the fanotify system call, which does allow recursive listening. They haven't implemented something using fanotify yet however.
Thanks, I didn't know about fanotify. Now I'm wondering why everything I use day-to-day (file syncing tools, IDEs, etc.) still seems to be stuck with inotify if there is a better option on modern operating systems. Maybe some of them are actually using fanotify under the hood, despite components still having "inotify" in their name.
In the original fanotify API,
only a limited set of events was supported. In particular, there
was no support for create, delete, and move events. The support
for those events was added in Linux 5.1. (See inotify(7) for
details of an API that did notify those events pre Linux 5.1.)
My guess is that inotify is so slow with large directories that it wasn't worth it. Plus inotify has cumbersome user limits.
inotify has a number of other relevant limitations, like not being able to create recursive notifications or handle "move" operations. Implementation effort is going to be way higher for an inotify-based system, and of course that's made far worse by the numerous file systems in linux - I imagine any implementation would probably start first with ext4.
I suspect an ideal solution would be via ebpf, but I'm not sure.
My assumption was that on Linux it's just been using inotify or something for a while and so hasn't needed a bespoke monitor. I have no idea if that's true or makes sense though.
Not sure why the response got downvoted. I personally found Git performance to be, well, okay on macOS (but depends) and absolutely horrible on Windows due to very slow stat() calls on NTFS.
Of course, in a large enough monorepo Linux performance would also suffer, but to a much lesser degree.
Also, conveniently, both Windows and macOS have an API for recursive directory watch, whereas Linux doesn't (in Vanilla kernel). Inotify can only watch the immediate directory you're observing + there's a pretty low default limit on the number of inotify descriptors that you're allowed to have on top of that
We've found this to be basically true. Git operations that stat() a lot are dramatically, catastrophically slower on OS X, and that's part of why my employer started doing fs watching there and mostly left Linux as is.
More than once I've had to update a cross-platform tool to avoid stat()ing because though cheap on Linux, it took 10s of seconds on OS X.
Are there any other git features with this limitation? Wild to me that we're here.
Thankfully the article covers the semi-longstanding "hooks" that existing (& very high performance) tools like Watchman (which are cross platform) can use.
Great in depth read. Good stuff! From the 2.37 release[1].
[1] https://github.blog/2022-06-27-highlights-from-git-2-37/ https://news.ycombinator.com/item?id=31898261 (34 points, 2 days ago, 7 comments)