7 ms·
Wow. I wasn't expecting anything like a filesystem monitor in git(1) itself. They post says Jeff Hostetler, the author of the patches, will make a blog post de
by tony 4y ago
Wow. I wasn't expecting anything like a filesystem monitor in git(1) itself.
They post says Jeff Hostetler, the author of the patches, will make a blog post delving into it. So it's worth bookmarking that post and swinging back. It's bound to be an interesting one!
Apparently git 2.16 had a fsmonitor hook for external filewatcher like watchman (it got passed me): https://github.com/git/git/commit/def4376711f607914bfb784f8de21867062fa284 https://github.com/git/git/commit/def4376711f607914bfb784f8d...
This kind of change needs to be tailored to the platform, it says just Mac (FSEvents?) and Windows (ReadDirectoryChangesW?) for now. So can we expect Linux (inotify?) and BSD (kqueue*) in the future?
Anyway, I hope this venture is fruitful. The premise of having cross-platform file watching without needing an extra application is delightful.
Thank you Jeff!
* I believe one area that may be tricky is kqueue, I believe it has limits in watching directories, needing a file descriptor for each file.
P.S. I would like to drop a link to entr(1), a lightweight cross platform file watcher: https://eradman.com/entrproject/ https://eradman.com/entrproject/
- jeffhostetler 4y agoThanks! And yes, I'll have a blog post on it. It is currently scheduled to appear on Wednesday on the GitHub blog. The new `git fsmonitor--daemon` is mostly shared code but with custom "backends" for each platform hidden a small API. Yes, the Mac backend is built using FSEvents. The Windows backend uses ReadDirectoryChangesW. In both cases, the backend has a thread dedicated to receiving these events/notifications from the kernel, normalizing them, and queuing them for future client requests. For sanity reasons, I had to draw the line at two platforms in the initial implementation. There have been discussions about doing a Linux version using either inotify or fanotify, but that work has not started. (And $dayjob might keep me busy for a while on other things, so I'm open to others picking up that work.) It shouldn't be too hard given the API boundary and threading that I set up. Likewise, for BSD.
- rektide 4y agoHere it is! https://github.blog/2022-06-29-improve-git-monorepo-performance-with-a-file-system-monitor/ https://github.blog/2022-06-29-improve-git-monorepo-performa... https://news.ycombinator.com/item?id=31924554 https://news.ycombinator.com/item?id=31924554
- tony 4y agoNice, thanks for linking this
- tony 4y agoGood that you are on HN now and thanks for this message. I ended up fetching git 2.37 (from whatever the default Ubuntu impish is at, I believe 2.32) (I don't know any benchmarking tools for `git(1)`, if your or anyone else does I'm all ears). I opened up `tig(1)` and `gitui(1)` in a large repo, stuff feels snappier. It could be a placebo. When trying to track where it could be coming from, I have trouble pinning it down: - 2.33.0: https://github.com/git/git/blob/v2.33.0/Documentation/RelNotes/2.33.0.txt https://github.com/git/git/blob/v2.33.0/Documentation/RelNot... - 2.34.0: https://github.com/git/git/blob/v2.34.0/Documentation/RelNotes/2.34.0.txt https://github.com/git/git/blob/v2.34.0/Documentation/RelNot... - 2.35.0: https://github.com/git/git/blob/v2.35.0/Documentation/RelNotes/2.35.0.txt https://github.com/git/git/blob/v2.35.0/Documentation/RelNot... - 2.36.0: https://github.com/git/git/blob/v2.36.0/Documentation/RelNotes/2.36.0.txt https://github.com/git/git/blob/v2.36.0/Documentation/RelNot... - 2.37.0: https://github.com/git/git/blob/v2.37.0/Documentation/RelNotes/2.37.0.txt https://github.com/git/git/blob/v2.37.0/Documentation/RelNot... This is a VCS that's getting a lot of care given to it.