Re: What's cooking in git.git (Jun 2021, #07; Wed, 30)

> 
> On Wed, Jun 30 2021, Junio C Hamano wrote:
> 
>> * jh/builtin-fsmonitor (2021-05-24) 30 commits
>>   - t/perf: avoid copying builtin fsmonitor files into test repo
>>   - t7527: test status with untracked-cache and fsmonitor--daemon
>>   - p7519: add fsmonitor--daemon
>>   - t7527: create test for 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
>>   - 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--daemon: implement daemon command options
>>   - 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 client command options
>>   - fsmonitor--daemon: add a built-in fsmonitor daemon
>>   - fsmonitor: introduce `core.useBuiltinFSMonitor` to call the daemon via IPC
>>   - config: FSMonitor is 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.
>>   - Merge branch 'jk/perf-in-worktrees' into HEAD
>>   - Merge branch 'jh/simple-ipc' into jh/rfc-builtin-fsmonitor
>>
>>   An attempt to write and ship with a watchman equivalent tailored
>>   for our use.
>>
>>   What's the status of this one?
> 
> I think Johannes's reply to the last WC applies[1]:
> 
>      I am not Jeff, but I know that he is busy getting back to it, and
>      plans on submitting a third iteration.
> 
> FWIW I'm still curious about some details on the performance concerns
> that seem to have prompted this built-in fsmonitor endeavor, as I asked
> about (but didn't get a reply to) in [2].
> 
> Not as a "we shouldn't have this, let's keep using the hook", but just
> curiosity about why we've seemingly gotten such different performance
> numbers on the watchman hook v.s. a built-in approach.
> 
> I suspect (but don't know) that the reason is that the built-in is
> perhaps integrating differently with git somehow, in a way that we could
> retrofit the hook approach to also do (if anyone still cares about the
> hook approach).
> 
> In any case I'm interested in *why* the new approach is faster, given
> that I've done some testing (again, noted in [2]) that suggest that
> bottleneck in the previous pipeline wasn't at all what Jeff H. thought
> it was.
> 
> 1. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2106171135530.57@tvgsbejvaqbjf.bet/#t
> 2. https://lore.kernel.org/git/87h7lgfchm.fsf@evledraar.gmail.com/
>