Re: Windows: core.useBuiltinFSMonitor without core.untrackedcache - performance hazard?

Fwiw, I've now submitted a patch(set) that I believe addresses this
particular issue correctly:

https://lore.kernel.org/git/pull.986.git.1624559401.gitgitgadget@gmail.com/ (local)

Thanks,
Tao

On Mon, Jun 21, 2021 at 10:52 PM Tao Klerks [off-list ref] wrote:

Hi Jeff, thanks for the update!

On Mon, Jun 21, 2021 at 8:41 PM Jeff Hostetler [off-list ref] wrote:

quoted

We're currently looking at a problem that we believe is in the
untracked-cache code.  This is causing some of our Scalar tests
to fail on Windows when the untracked-cache is turned on.

For what it's worth, I just discovered an untracked cache bug this
evening, although I doubt it's related to the one you mention - it's
not very exciting:

If you disable untracked cache (and write an index file), and then
enable untracked cache and run status with "-uall" (writing a new
index file), the untracked cache data written in the new index file is
empty/invalid, and subsequent "git status" calls perform just the same
as if untracked cache were disabled:
----
# write an index without untracked cache
git -c core.untrackedcache=false status

# write another index with invalid/empty/bad untracked cache because
"-uall" skipped its population/maintenance
git -c core.untrackedcache=true status -uall # expected to be slow

# run regular "git status" (with untracked cache) any number of times,
but don't get the benefit (and you don't write a new index because
nothing appears to have changed)
git -c core.untrackedcache=true status # unexpectedly slow
git -c core.untrackedcache=true status # unexpectedly slow
git -c core.untrackedcache=true status # unexpectedly slow
---
# TO FIX:
# write a new index file without untracked cache
git -c core.untrackedcache=false status

# run regular "git status" (with untracked cache), does work and
writes a new index file
git -c core.untrackedcache=true status # slow as expected

# run regular "git status" (with untracked cache) any number of times,
is fast as expected
git -c core.untrackedcache=true status # fast as expected
git -c core.untrackedcache=true status # fast as expected
git -c core.untrackedcache=true status # fast as expected
----

I suspect this issue has bit me in the past when attempting to
understand untracked cache behavior; it can be *very* confusing, if
you're using tooling like "git extensions" that can, in the above
flow, "poison" your untracked cache if it just happens to run a "git
status -uall" in the background as you are testing.

(I discovered this issue while trying to understand the weird &
wonderful relationship between the repo-level untracked cache
reference, the dir-level untracked cache reference, and the mechanisms
that initialize a new one at dir.c#new_untracked_cache() and write the
repo-level one (even if the dir-level reference was voided due to flag
mismatch) at dir.c#write_untracked_extension())

Should I be reporting this in some more "official" form somewhere? Is
there a bug DB?

Thanks,
Tao