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

>
> Hi Jeff, thanks for the update!
>
> On Mon, Jun 21, 2021 at 8:41 PM Jeff Hostetler <git@jeffhostetler.com> wrote:
> > 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