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

From: Tao Klerks <tao@klerks.biz>
Date: Jun 21, 2021, 20:52 UTC
Message-ID: <CAPMMpogjr43111HfPzk23c98JBaiEF2YA_OTkQVG1a63zyeiOw@mail.gmail.com>
In-Reply-To: <81153d02-8e7a-be59-e709-e90cd5906f3a@jeffhostetler.com>

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