From: Matthew Hughes <matthewhughes934@gmail.com>
Date: Mon, 06 Oct 2025 17:25:51 GMT
Subject: Re: Untracked files cache not used when --untracked-files is used
Message-ID: <l62blkvi5ouzhkbfmimumhzdkv6tmszsxuxhlfkmu2lkspyihy@75466fqmo6ez>
In-Reply-To: <CANM0SV38YcQ+THbAyTR5cnaX3iDfb92qG8gyAzUaJ5jMK7FfYQ@mail.gmail.com>

> 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.