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@xxxxxxxxx/ Thanks, Tao On Mon, Jun 21, 2021 at 10:52 PM Tao Klerks <tao@xxxxxxxxxx> wrote: > > 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
