# Untracked files cache not used when --untracked-files is used 5 messages from 2025-10-03 to 2025-10-07. Participants: Devste Devste, Matthew Hughes. Thread: https://gitlist.dev/t/64243 ## Devste Devste, 2025-10-03 11:05 Subject: Untracked files cache not used when --untracked-files is used Message-ID: URL: https://gitlist.dev/e/CANM0SV3%2B4k5tsgRw0g8-HoVSFGb1AwZr%2B2hCUXLriFGSd33WQQ%40mail.gmail.com ``` I am using: git version 2.51.0.windows.1 Run: time git status --untracked-files I get: It took 2.75 seconds to enumerate untracked files, but the results were cached, and subsequent runs may be faster. See 'git help status' for information on how to improve this. real 0m2.959s user 0m0.000s sys 0m0.000s --- when I run it again, I get the same thing again However, when I run it again WITHOUT --untracked-files its much faster now: real 0m0.753s user 0m0.000s sys 0m0.015s which means that the untracked cache does work (bc deleting the untracked cache, it will be slow and also show the message) per the docs: >When -u option is not used, untracked files and directories are shown (i.e. the same as specifying normal) Which I can confirm also with: git update-index --test-untracked-cache >Testing mtime in 'C:/Foo/bar' ...... OK It seems that using --untracked-files(=all) causes it to either not use the untracked files cache (or untracked files are not stored in the untracked files cache if they are in an untracked directory?) Since various tools and IDEs use that hardcoded, fixing this would be a massive performance boost for many users ``` ## Matthew Hughes, 2025-10-05 00:20 Subject: Re: Untracked files cache not used when --untracked-files is used Message-ID: URL: https://gitlist.dev/e/lrahpvp3nj4rtewf3zbf67qsvwhc4mg6irbmrhklbizxbhqwom%40cc25oeqex4il In-Reply-To: ``` Devste Devste wrote: > It seems that using --untracked-files(=all) causes it to either not > use the untracked files cache (or untracked files are not stored in > the untracked files cache if they are in an untracked directory?) > Since various tools and IDEs use that hardcoded, fixing this would be > a massive performance boost for many users What's the value of your `status.showUntrackedFiles` config var? I ask because I looked around a bit and found commit e6a653554bb49c26d105f3b478cbdbb1c0648f65 (untracked-cache: support '--untracked-files=all' if configured), which includes: > For most users there will be no change in behavior. Users who need > '--untracked-files=all' to perform well will now have the option of > setting "status.showuntrackedfiles" to "all" for better / more > consistent performance. Testing this out on a big repo (on my Linux machine): $ git init . # create ~100_000 files with plenty of directories $ for i in {1..10000}; do echo dir_$i/{1,2,3,4}/nested_{1,2}; done | xargs mkdir -p $ for i in {1..10000}; do echo dir_$i/{foo,bar,baz}/file.txt; done | xargs touch $ git add . As expected, status with untracked files and no untracked cache is rather slow: $ time GIT_CONFIG_GLOBAL=/dev/null git status --untracked-files=all >/dev/null real 0m1.237s user 0m0.484s sys 0m1.150s Status with untracked files and `core.untrackedCache=true` is just as slow: $ time GIT_CONFIG_GLOBAL=/dev/null git -c 'core.untrackedCache=true' status --untracked-files=all >/dev/null real 0m1.250s user 0m0.435s sys 0m1.216s However, with `status.untrackedFiles=all` (i.e. matching the `--untracked-files` flag) it's much quicker: $ time GIT_CONFIG_GLOBAL=/dev/null git -c 'core.untrackedCache=true' -c 'status.showUntrackedFiles=all' status --untracked-files=all >/dev/null real 0m0.382s user 0m0.214s sys 0m0.568s ``` ## Devste Devste, 2025-10-05 11:14 Subject: Re: Untracked files cache not used when --untracked-files is used Message-ID: URL: https://gitlist.dev/e/CANM0SV38YcQ%2BTHbAyTR5cnaX3iDfb92qG8gyAzUaJ5jMK7FfYQ%40mail.gmail.com In-Reply-To: ``` Thank you, this solved the problem indeed, status.showUntrackedFiles was not set at all in my case. However: it did not work/update the cache initially with the command the IDE/GUI usually runs: git config status.showUntrackedFiles all time git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status --porcelain --ignore-submodules=dirty --untracked-files=all --no-ahead-behind real 0m3.463s user 0m0.000s sys 0m0.000s time git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status --porcelain --ignore-submodules=dirty --untracked-files=all --no-ahead-behind real 0m3.423s user 0m0.031s sys 0m0.015s time git status --untracked-files ... It took 3.41 seconds to enumerate untracked files, but the results were cached, and subsequent runs may be faster. See 'git help status' for information on how to improve this. ... real 0m3.691s user 0m0.000s sys 0m0.015s time git status --untracked-files ... real 0m0.773s user 0m0.000s sys 0m0.000s time git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status --porcelain --ignore-submodules=dirty --untracked-files=all --no-ahead-behind ... real 0m0.818s user 0m0.000s sys 0m0.015s --- One of --no-optional-locks --porcelain --ignore-submodules=dirty --no-ahead-behind causes it to not update the cache it seems. Unfortunately, I cannot tell which exactly, because now, even when unsetting status.showUntrackedFiles it uses the cache for --untracked-files=all This means, that if the untracked cache was created with status.showUntrackedFiles all, it will always use the untracked-files cache for --untracked-files On Sun, 5 Oct 2025 at 02:20, Matthew Hughes wrote: > > Devste Devste wrote: > > It seems that using --untracked-files(=all) causes it to either not > > use the untracked files cache (or untracked files are not stored in > > the untracked files cache if they are in an untracked directory?) > > Since various tools and IDEs use that hardcoded, fixing this would be > > a massive performance boost for many users > > What's the value of your `status.showUntrackedFiles` config var? I ask because > I looked around a bit and found commit e6a653554bb49c26d105f3b478cbdbb1c0648f65 > (untracked-cache: support '--untracked-files=all' if configured), which > includes: > > > For most users there will be no change in behavior. Users who need > > '--untracked-files=all' to perform well will now have the option of > > setting "status.showuntrackedfiles" to "all" for better / more > > consistent performance. > > Testing this out on a big repo (on my Linux machine): > > $ git init . > # create ~100_000 files with plenty of directories > $ for i in {1..10000}; do echo dir_$i/{1,2,3,4}/nested_{1,2}; done | xargs mkdir -p > $ for i in {1..10000}; do echo dir_$i/{foo,bar,baz}/file.txt; done | xargs touch > $ git add . > > As expected, status with untracked files and no untracked cache is rather slow: > > $ time GIT_CONFIG_GLOBAL=/dev/null git status --untracked-files=all >/dev/null > > real 0m1.237s > user 0m0.484s > sys 0m1.150s > > Status with untracked files and `core.untrackedCache=true` is just as slow: > > $ time GIT_CONFIG_GLOBAL=/dev/null git -c 'core.untrackedCache=true' status --untracked-files=all >/dev/null > > real 0m1.250s > user 0m0.435s > sys 0m1.216s > > However, with `status.untrackedFiles=all` (i.e. matching the `--untracked-files` flag) it's much quicker: > > $ time GIT_CONFIG_GLOBAL=/dev/null git -c 'core.untrackedCache=true' -c 'status.showUntrackedFiles=all' status --untracked-files=all >/dev/null > > real 0m0.382s > user 0m0.214s > sys 0m0.568s ``` ## Matthew Hughes, 2025-10-06 17:25 Subject: Re: Untracked files cache not used when --untracked-files is used Message-ID: URL: https://gitlist.dev/e/l62blkvi5ouzhkbfmimumhzdkv6tmszsxuxhlfkmu2lkspyihy%4075466fqmo6ez In-Reply-To: ``` > One of --no-optional-locks --porcelain --ignore-submodules=dirty > --no-ahead-behind causes it to not update the cache it seems. > Unfortunately, I cannot tell which exactly, because now, even when > unsetting status.showUntrackedFiles it uses the cache for > --untracked-files=all > This means, that if the untracked cache was created with > status.showUntrackedFiles all, it will always use the untracked-files > cache for --untracked-files You can disable the untracked cache with `git update-index --no-untracked-cache`. Experimenting with that, on my machine the culprit looks to be `--no-optional-locks`: time GIT_CONFIG_GLOBAL=/dev/null git \ --no-optional-locks \ -c 'diff.mnemonicprefix=false' \ -c 'core.quotepath=false' \ -c 'core.untrackedCache=true' \ -c 'status.showUntrackedFiles=all' \ status \ --porcelain \ --ignore-submodules=dirty \ --no-ahead-behind \ --untracked-files=all >/dev/null Will consistently, on repeated runs, take >1s. After removing `--no-optional-locks` one more run is still slow, but after that it drops to ~300ms. Glancing at the code: the likely cause is the `repo_update_index_if_able` call in `cmd_status` is only called when `use_optional_locks` returns a truthy value. ``` ## Devste Devste, 2025-10-07 09:14 Subject: Re: Untracked files cache not used when --untracked-files is used Message-ID: URL: https://gitlist.dev/e/CANM0SV1p3auirRoHTfh2r%3DJuP-QU7uyK4o1%2BPZNVPT1mCVSqXw%40mail.gmail.com In-Reply-To: ``` Which means essentially, I have to run git status --untracked-files once a day to keep the untracked cache up to date, since I can't change the git commands SourceTree uses On Mon, 6 Oct 2025 at 19:25, Matthew Hughes wrote: > > > One of --no-optional-locks --porcelain --ignore-submodules=dirty > > --no-ahead-behind causes it to not update the cache it seems. > > Unfortunately, I cannot tell which exactly, because now, even when > > unsetting status.showUntrackedFiles it uses the cache for > > --untracked-files=all > > This means, that if the untracked cache was created with > > status.showUntrackedFiles all, it will always use the untracked-files > > cache for --untracked-files > > You can disable the untracked cache with `git update-index > --no-untracked-cache`. Experimenting with that, on my machine the culprit looks > to be `--no-optional-locks`: > > time GIT_CONFIG_GLOBAL=/dev/null git \ > --no-optional-locks \ > -c 'diff.mnemonicprefix=false' \ > -c 'core.quotepath=false' \ > -c 'core.untrackedCache=true' \ > -c 'status.showUntrackedFiles=all' \ > status \ > --porcelain \ > --ignore-submodules=dirty \ > --no-ahead-behind \ > --untracked-files=all >/dev/null > > Will consistently, on repeated runs, take >1s. After removing > `--no-optional-locks` one more run is still slow, but after that it drops to > ~300ms. > > Glancing at the code: the likely cause is the `repo_update_index_if_able` call > in `cmd_status` is only called when `use_optional_locks` returns a truthy > value. ```