How do I get rid of the warning "Untracked cache is disabled on this system."

Question

When running git status I often get multiple warnings:

$ git status
warning: Untracked cache is disabled on this system.
warning: Untracked cache is disabled on this system.
warning: Untracked cache is disabled on this system.
warning: Untracked cache is disabled on this system.
warning: Untracked cache is disabled on this system.
warning: Untracked cache is disabled on this system.
warning: Untracked cache is disabled on this system.
warning: Untracked cache is disabled on this system.

I've added this to my .gitconfig:

[core]
untrackedCache = true

And even tried running git update-index --untracked-cache. However that didn't help.

Using git v2.7.4 on Ubuntu Xenial.

What's causing these warnings and how do I get rid of them (without piping errors to /dev/null)?

Answer 1

(VonC's question is a key clue: the untracked cache requires that the work tree path match that stored in the index. Also, the system name, from uname's utsname field, is kept there and also must match; this affects files that are managed across a networked file system such as NFS or SMB.)

Since the untracked cache is disabled on your system and leads to warnings, you might want not to attempt to enable it. In other words, leave core.untrackedCache unset, or set it to false. However, core.untrackedCache is a new setting in Git version 2.8.0; if your Git is 2.7.4 you don't have it.

Running git update-index --untracked-cache forces the setting on (and then produces all those error messages). You can use git update-index --no-untracked-cache to force it off. The only bad effect is that git status may run slower (possibly significantly slower) when the untracked cache is disabled.

Note that as of 2.8.0, Git recommends running git update-index --test-untracked-cache before enabling the untracked cache (with either --untracked-cache or core.untrackedCache = true). Note, too, that if this is core setting is set to true or false, the core.untrackedCache setting is simply copied to the index when the index is updated (with git update-index). It's actually the index's setting that controls things. Using the default (unset) or setting it to keep tells Git to leave the untracked-cache setting alone.

You can also set the environment variable GIT_DISABLE_UNTRACKED_CACHE (to any value) to disable the use of the untracked cache, regardless of the current setting in the index. (This code appears to be in 2.7.4 as well.) This will bypass the warning, and not use the untracked cache, regardless of the setting in the index.

Answer 2

how do I get rid of them

Note: you should see less of those messages, at least, with Git 2.17 (Q2 2018)
Writing out the index file when the only thing that changed in it is the untracked cache information is often wasteful, and this has been optimized out.

See commit fc9ecbe (05 Feb 2018) by Ben Peart (benpeart).
^{(Merged by Junio C Hamano -- gitster -- in commit cdda65a, 08 Mar 2018)}

dir.c: don't flag the index as dirty for changes to the untracked cache

The untracked cache saves its current state in the UNTR index extension. Currently, any change to that state causes the index to be flagged as dirty and written out to disk.
Unfortunately, the cost to write out the index can exceed the savings gained by using the untracked cache.
Since it is a cache that can be updated from the current state of the working directory, there is no functional requirement that the index be written out for every change to the untracked cache.

Update the untracked cache logic so that it no longer forces the index to be written to disk except in the case where the extension is being turned on or off.
When some other git command requires the index to be written to disk, the untracked cache will take advantage of that to save it's updated state as well.

This results in a performance win when looked at over common sequences of git commands (ie such as a status followed by add, commit, etc).

---

Git 2.24 clarifies the core.untrackedCache setting:

See commit aaf633c, commit c6cc4c5, commit ad0fb65, commit 31b1de6, commit b068d9a, commit 7211b9e (13 Aug 2019) by Derrick Stolee (derrickstolee).
^{(Merged by Junio C Hamano -- gitster -- in commit f4f8dfe, 09 Sep 2019)}

repo-settings: parse core.untrackedCache

The core.untrackedCache config setting is slightly complicated, so clarify its use and centralize its parsing into the repo settings.

The default value is "keep" (returned as -1), which persists the untracked cache if it exists.

If the value is set as "false" (returned as 0), then remove the untracked cache if it exists.

If the value is set as "true" (returned as 1), then write the untracked cache and persist it.

Instead of relying on magic values of -1, 0, and 1, split these options into an enum.
This allows the use of "-1" as a default value.
After parsing the config options, if the value is unset we can initialize it to UNTRACKED_CACHE_KEEP.

---

With Git 2.36 (Q2 2022), fix the setting core.untrackedCache which, when set to true, failed to add the untracked cache extension to the index.

See commit 26b8946 (17 Feb 2022) by Derrick Stolee (derrickstolee).
^{(Merged by Junio C Hamano -- gitster -- in commit 80f7f61, 25 Feb 2022)}

dir: force untracked cache with core.untrackedCache

^{Signed-off-by: Derrick Stolee}

The GIT_FORCE_UNTRACKED_CACHE environment variable writes the untracked cache more frequently than the core.untrackedCache config variable.
This is due to how read_directory() handles the creation of an untracked cache.

Before this change, Git would not create the untracked cache extension for an index that did not already have one.
Users would need to run a command such as 'git update-index --untracked-cache'^(man) before the index would actually contain an untracked cache.

In particular, users noticed that the untracked cache would not appear even with core.untrackedCache=true.
Some users reported setting GIT_FORCE_UNTRACKED_CACHE=1 in their engineering system environment to ensure the untracked cache would be created.

The decision to not write the untracked cache without an environment variable tracks back to fc9ecbe ("dir.c: don't flag the index as dirty for changes to the untracked cache", 2018-02-05, Git v2.17.0-rc0 -- merge listed in batch #8).
The motivation of that change is that writing the index is expensive, and if the untracked cache is the only thing that needs to be written, then it is more expensive than the benefit of the cache.
However, this also means that the untracked cache never gets populated, so the user who enabled it via config does not actually get the extension until running 'git update-index --untracked-cache' manually or using the environment variable.

We have had a version of this change in the microsoft/git fork for a few major releases now.
It has been working well to get users into a good state.
Yes, that first index write is slow, but the remaining index writes are much faster than they would be without this change.