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