[PATCH v3 0/3] Empty untracked cache performance issue

This patchset addresses a performance issue with untracked cache. When a new untracked cache structure is added to the index but remains empty, subsequent "git status" calls populate it but do not write the index - so they perform as though the index were disabled.

This situation can be caused in several different ways:

 * Running "git update-index --untracked-cache" on a repo that did not have
   the untracked cache
 * Modifying the git configuration to enable untracked cache, but then
   immediately running "git status -uall", causing the untracked cache to be
   created, but not used/populated (and the index written).
 * (likely others)

The patchset includes fixes to t7519, which otherwise starts failing because it wasn't testing what it intended to.

Tao Klerks (3):
  t7519: avoid file to index mtime race for untracked cache
  t7519: populate untracked cache before test
  untracked-cache: write index when populating empty untracked cache

 dir.c                       | 10 +++++++---
 t/t7519-status-fsmonitor.sh |  7 +++++++
 2 files changed, 14 insertions(+), 3 deletions(-)

base-commit: 4c53a8c20f8984adb226293a3ffd7b88c3f4ac1a
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-986%2FTaoK%2Ftaok-empty-untracked-cache-bug-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-986/TaoK/taok-empty-untracked-cache-bug-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/986

Range-diff vs v2:

 1:  9421b71540d ! 1:  8b1f89c259e t7519: avoid file to index mtime race for untracked cache
     @@ Commit message
          t7519: avoid file to index mtime race for untracked cache
      
          In t7519 there is a test that writes files to disk, and immediately
     -    writes the untracked index. Because of mtime-comparison logic that
     -    uses a 1-second resolution, this means the cached entries are not
     -    trusted/used under some circumstances
     +    writes the index with the untracked cache. Because of
     +    mtime-comparison logic that uses a 1-second resolution, this means
     +    the cached entries are not trusted/used under some circumstances
          (see read-cache.c#is_racy_stat()).
      
          Untracked cache tests in t7063 use a 1-second delay to avoid this
          issue, but we don't want to introduce arbitrary slowdowns, so instead
     -    use test-tool chmtime to backdate the files slightly.
     +    use test-tool chmtime to backdate the files slightly. The t7063
     +    delays are a #leftoverbit, to be worked on in a separate series.
      
          This change doesn't actually affect the outcome of the test, but does
          enhance its validity, and becomes relevant after later changes.
 2:  d29a68e65a0 = 2:  c901f9d96ca t7519: populate untracked cache before test
 3:  190b27e518a = 3:  9795a08414a untracked-cache: write index when populating empty untracked cache