]> git.ipfire.org Git - thirdparty/git.git/commit
update-index: refresh should rewrite index in case of racy timestamps
authorMarc Strapetz <marc.strapetz@syntevo.com>
Fri, 7 Jan 2022 11:17:31 +0000 (11:17 +0000)
committerJunio C Hamano <gitster@pobox.com>
Fri, 7 Jan 2022 20:37:31 +0000 (12:37 -0800)
commit2ede073fd2287eb91af26484c2e7dafc15ecb7b7
treed6bdc4f6b4d5b8416b4f70e9cbc291e20c160ce5
parent9b71efd01489d6c93436740e4c1b3eadeb0c719b
update-index: refresh should rewrite index in case of racy timestamps

'git update-index --refresh' and '--really-refresh' should force writing
of the index file if racy timestamps have been encountered, as
'git status' already does [1].

Note that calling 'git update-index --refresh' still does not guarantee
that there will be no more racy timestamps afterwards (the same holds
true for 'git status'):

- calling 'git update-index --refresh' immediately after touching and
  adding a file may still leave racy timestamps if all three operations
  occur within the racy-tolerance (usually 1 second unless USE_NSEC has
  been defined)

- calling 'git update-index --refresh' for timestamps which are set into
  the future will leave them racy

To guarantee that such racy timestamps will be resolved would require to
wait until the system clock has passed beyond these timestamps and only
then write the index file. Especially for future timestamps, this does
not seem feasible because of possibly long delays/hangs.

[1] https://lore.kernel.org/git/d3dd805c-7c1d-30a9-6574-a7bfcb7fc013@syntevo.com/

Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/update-index.c
cache.h
read-cache.c
t/t2108-update-index-refresh-racy.sh [new file with mode: 0755]