Ah yes, thanks for linking that. So there was a discussion about a conflict with `--verbose` at least; whether to go for the upper case `-V` or completely drop the version flag from the patch. But then:
"I do not care too deeply, and it is the most time efficient to just
take the last patch as-is."
Good lord, what a pragmatic maintainer! Burn them at the stakes!
I'm disappointed they are deprecating the non-cone sparse-checkout style. Even if it messes with sparse indices, on Windows all my git operations are almost entirely dominated by individual file operations, not CPU or index operations.
I also agree they should keep it. From my understanding, the --no-cone mode is the only way to keep only some files inside a directory. Cone mode either includes all or none.
Etienne
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!
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.
Thanks! 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.
Good 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:
11 comments
[ 1.8 ms ] story [ 40.1 ms ] thread"git -v" and "git -h" are now understood as "git --version" and "git --help".
I wonder how many bikes were shed before that implementation could happen.
This is a first time contributor getting a headlining feature at the top of the release notes!
"I do not care too deeply, and it is the most time efficient to just take the last patch as-is."
Good lord, what a pragmatic maintainer! Burn them at the stakes!
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/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/
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.
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/RelNot...
- 2.34.0: https://github.com/git/git/blob/v2.34.0/Documentation/RelNot...
- 2.35.0: https://github.com/git/git/blob/v2.35.0/Documentation/RelNot...
- 2.36.0: https://github.com/git/git/blob/v2.36.0/Documentation/RelNot...
- 2.37.0: 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.