RE: [PATCH 0/1] fsmonitor: fix watchman integration

From: Kevin Willford <kevin.willford@microsoft.com>
Date: Nov 6, 2019, 15:32 UTC
Message-ID: <BN6PR21MB0786856156CFB55E8812D51E91790@BN6PR21MB0786.namprd21.prod.outlook.com>
In-Reply-To: <xmqqlfstvg09.fsf@gitster-ct.c.googlers.com>

Show 15 quoted lines

> From: Junio C Hamano <gitster@pobox.com>
> Sent: Tuesday, November 5, 2019 8:30 PM
> 
> "Kevin Willford via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > When running Git commands quickly -- such as in a shell script or the
> > test suite -- the Git commands frequently complete and start again
> > during the same second. The example fsmonitor hooks to integrate with
> > Watchman truncate the nanosecond times to seconds. In principle, this
> > is fine, as Watchman claims to use inclusive comparisons [1]. The
> > result should only be an over-representation of the changed paths since
> the last Git command.
> > ...
> 
> So, it doesn't seem to use "inclusive" and we need a workaround?

That is what is seems like. I would like to dig into the watchman code to understand what is really going on. They also document that "Using a timestamp is prone to race conditions in understanding the complete state of the file tree." Which could be the cause since the tests are running things in quick succession, i.e. change a file, run a git command.

Long term we should switch to using watchman's clock id which the documentation says does not have the race conditions. But the clock id is a string and would take more invasive changes to integrate that into the index where we are now simply using a uint64_t.