undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'ab/untracked-cache-invalidation-docs'

Browse Source 
Doc update to warn against remaining bugs in untracked cache.

* ab/untracked-cache-invalidation-docs:
  update-index doc: note the caveat with "could not open..."
  update-index doc: note a fixed bug in the untracked cache
This commit is contained in:
Junio C Hamano 2018-02-27 10:33:50 -08:00
commit c6e3ac0f69
1 changed files with 26 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/git-update-index.txt
View File

@ -464,6 +464,32 @@ command reads the index; while when `--[no-|force-]untracked-cache`
are used, the untracked cache is immediately added to or removed from
the index.
Before 2.17, the untracked cache had a bug where replacing a directory
with a symlink to another directory could cause it to incorrectly show
files tracked by git as untracked. See the "status: add a failing test
showing a core.untrackedCache bug" commit to git.git. A workaround for
that is (and this might work for other undiscovered bugs in the
future):
----------------
$ git -c core.untrackedCache=false status
----------------
This bug has also been shown to affect non-symlink cases of replacing
a directory with a file when it comes to the internal structures of
the untracked cache, but no case has been reported where this resulted in
wrong "git status" output.
There are also cases where existing indexes written by git versions
before 2.17 will reference directories that don't exist anymore,
potentially causing many "could not open directory" warnings to be
printed on "git status". These are new warnings for existing issues
that were previously silently discarded.
As with the bug described above the solution is to one-off do a "git
status" run with `core.untrackedCache=false` to flush out the leftover
bad data.
File System Monitor
-------------------