Re: Detecting when bulk file-system operations complete

[Derrick Stolee <stolee@gmail.com>]

On 3/31/2021 12:03 PM, Philip Oakley wrote:
> Hi Drew,
> 
> On 31/03/2021 04:39, Drew Noakes wrote:
>> Hi,
>>
>> I develop IDE tooling that watches a repo's workspace and reacts to changes.
>>
>> Bulk file-system changes (i.e. branch switch, rebase, merge,
>> cherry-pick) trigger lots of file system events, and my tooling should
>> ignore intermediary updates. Currently I debounce events with a fixed
>> time span, but would like a more reliable and performant approach to
>> scheduling this reactive work.
>>
>> Can this be done by monitoring the GITDIR in some way? For example, is
>> there a file that's present when these operations are in flight, and
>> which is removed when they complete?
>>
>> If an operation is interrupted (i.e. merge or rebase that hits a
>> conflict) my tooling should consider the bulk operation as complete.
>> This means that detecting a git-rebase-todo file or
>> rebase-merge/rebase-apply folder is not adequate.
>>
>> Any help appreciated. Thanks!
>>
>> Drew.
> You may want to look at the various bits of work on `fsmonitor` etc on
> the mailing list archive
> 
> https://lore.kernel.org/git/?q=fsmonitor
> 
> to ensure that all the different approaches inter-operate with
> reasonable efficiency..

This is an important suggestion. There is an issue with the current
approach of using FS Monitor with Watchman along with Visual Studio
Code and certain Git plugins:

1. When "git status" runs, the FS Monitor hook asks Watchman for
   changes. Watchman puts a "cookie file" in the working directory
   so it knows when the file system events are flushed.

2. VS Code notices this cookie file was written, so it interprets
   that a file was changed in the working directory. It calls
   "git status" to update its markers on the modified files.

This loops forever.

The new version of FS Monitor that Jeff Hostetler is working on
writes the cookie file into the .git directory, which VS Code (and
hopefully other IDEs) do not consider a trigger for running commands
like "git status".

This is just one example of the trickiness that ensues when using
filesystem events.

Thanks,
-Stolee