On 7/27/21 12:55 AM, Junio C Hamano wrote:
* jh/builtin-fsmonitor (2021-07-12) 35 commits - BANDAID: sparse fixes - t7527: test FS event reporing on MacOS WRT case and Unicode - fsmonitor: handle shortname for .git - t7527: test status with untracked-cache and fsmonitor--daemon - fsmonitor: force update index after large responses - fsmonitor: enhance existing comments - fsmonitor--daemon: use a cookie file to sync with file system - fsmonitor--daemon: periodically truncate list of modified files - t7527: create test for fsmonitor--daemon - t/perf/p7519: add fsmonitor--daemon test cases - t/perf: avoid copying builtin fsmonitor files into test repo - t/perf/p7519: speed up test using "test-tool touch" - t/helper/test-touch: add helper to touch a series of files - fsmonitor--daemon: implement handle_client callback - fsmonitor-fs-listen-macos: implement FSEvent listener on MacOS - fsmonitor-fs-listen-macos: add macos header files for FSEvent - fsmonitor-fs-listen-win32: implement FSMonitor backend on Windows - fsmonitor--daemon: create token-based changed path cache - fsmonitor--daemon: define token-ids - fsmonitor--daemon: add pathname classification - fsmonitor: do not try to operate on bare repos - fsmonitor--daemon: implement 'start' command - fsmonitor--daemon: implement 'run' command - fsmonitor-fs-listen-macos: stub in backend for MacOS - fsmonitor-fs-listen-win32: stub in backend for Windows - t/helper/fsmonitor-client: create IPC client to talk to FSMonitor Daemon - fsmonitor--daemon: implement 'stop' and 'status' commands - fsmonitor--daemon: add a built-in fsmonitor daemon - fsmonitor: use IPC to query the builtin FSMonitor daemon - fsmonitor: config settings are repository-specific - help: include fsmonitor--daemon feature flag in version info - fsmonitor-ipc: create client routines for git-fsmonitor--daemon - fsmonitor--daemon: update fsmonitor documentation - fsmonitor--daemon: man page - simple-ipc: preparations for supporting binary messages. An attempt to write and ship with a watchman equivalent tailored for our use. So, where are we with this topic?
I'm working on a V4 currently. It will try to address most of the V3 concerns raised on list as well as feedback and error reports from the beta testers of the experimental version in our downstream forks. At this point in the cycle leading up to v2.33, it would be fine to drop V3 from your nightly builds and avoid all of the distractions as you prepare for the release. I'll hold V4 until after the release. Thanks Jeff
