FSMonitor: deepening a directory causes confusing events

[jeffhostetler]

See git-for-windows#3456

Pulling this forward into microsoft/git so that we can test it here too.

[jeffhostetler]

The failure on windows-test (1) in t7527 step 56: Matrix[uc:true][fsm:false] move_directory is in the untracked-cache. It is turned on (and FSMonitor is off) and we are comparing the status output with the false/false case (where both are turned off).

I'm seeing a questionable entry in the untracked-cache when I dump it.

$ git -c core.usebuiltinfsmonitor=false status
warning: could not open directory 'T1/T3/': No such file or directory
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    T1/T2/T3/F1
        deleted:    T1/T2/T3/F2
        deleted:    T1/T2/T3/T4/F1
        deleted:    T1/T2/T3/T4/F2

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        T1/T2/NewT3/
        T1/T3/

no changes added to commit (use "git add" and/or "git commit -a")

$ ../helper/test-tool.exe dump-untracked-cache
info/exclude cc30ca8b9b10bb92f8e5c96ee94348c6c4ac93e6
core.excludesfile 0000000000000000000000000000000000000000
exclude_per_dir .gitignore
flags 00000006
/ 29bf0e0278da71c700d79b764e972e3ff0492d0f recurse valid
/T1/ 0000000000000000000000000000000000000000 recurse valid
T3/
/T1/T2/ 0000000000000000000000000000000000000000 recurse valid
/T1/T2/T3/ 0000000000000000000000000000000000000000 recurse valid
/T1/T2/T3/T4/ 0000000000000000000000000000000000000000 recurse valid
/T1/T3/ 0000000000000000000000000000000000000000 recurse
/dir1/ 0000000000000000000000000000000000000000 recurse valid
/dir2/ 0000000000000000000000000000000000000000 recurse valid
/dirtorename/ 0000000000000000000000000000000000000000 recurse valid

Why do we have a T3/ row?

Also, why are we getting that warning from git status?

The T1/T3 directory is left-over dirt from test 55 I believe.

[derrickstolee]

The failure on windows-test (1) in t7527 step 56: Matrix[uc:true][fsm:false] move_directory is in the untracked-cache. It is turned on (and FSMonitor is off) and we are comparing the status output with the false/false case (where both are turned off).

We know that the untracked cache is unreliable on Windows without the FS Monitor feature, but we have determined that it is reliable when we can count on the FS Monitor. Should we remove that possibility from the matrix?

[jeffhostetler]

@derrickstolee Hey, is your #415 series (or parts of it) going upstream?

The failure I described above is fixed (or at least, not currently happening) when
I set GIT_FORCE_UNTRACKED_CACHE in the my t7527 test script (like was done
in t7063.

Also, I found the following upstream which I thought might be significant here.

cdda65a (Merge branch 'bp/untracked-cache-noflush', 2018-03-08)
026336c (untracked cache: use git_env_bool() not getenv() for customization, 2018-02-28)
fc9ecbe (dir.c: don't flag the index as dirty for changes to the untracked cache, 2018-02-05)

[derrickstolee]

@derrickstolee Hey, is your #415 series (or parts of it) going upstream?

I should probably send 7e993e5 upstream for feedback.

The failure I described above is fixed (or at least, not currently happening) when I set GIT_FORCE_UNTRACKED_CACHE in the my t7527 test script (like was done in t7063.

Interesting. My change makes core.untrackedCache=true behave as if GIT_FORCE_UNTRACKED_CACHE=1. Since your setup sets core.untrackedCache=true and calls git update-index --untracked-cache, there should be no change from #415.

[jeffhostetler]

The more I tinker with this, the more I think we still haven't found the real problem.
Adding FORCE made some runs succeed, but others still failed. I want to take
some time (not today) and dig into the untracked-cache code on Windows and see
what's really going on.

[jeffhostetler]

I'm going to close this PR and replace it with #448 to (hopefully) cause a complete set of fresh builds.