From 7bf0be75016058e43181ecc22c65b363beb6d24b Mon Sep 17 00:00:00 2001 From: =?utf8?q?=C3=86var=20Arnfj=C3=B6r=C3=B0=20Bjarmason?= Date: Fri, 9 Feb 2018 21:04:31 +0000 Subject: [PATCH] update-index doc: note the caveat with "could not open..." MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Note the caveat where 2.17 is stricter about index validation potentially causing "could not open directory" warnings when git is upgraded. See the preceding "dir.c: stop ignoring opendir() error in open_cached_dir()" change. This caused some mayhem when I upgraded git to a version with this series at Booking.com, and other users have doubtless enabled the UC extension and are in for a surprise when they upgrade. Let's give them a headsup in the docs. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano --- Documentation/git-update-index.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt index f0e08d6a4c..b8d3c0d72e 100644 --- a/Documentation/git-update-index.txt +++ b/Documentation/git-update-index.txt @@ -480,6 +480,16 @@ 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 ------------------- -- 2.11.4.GIT