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>
This commit is contained in:
committed by
Junio C Hamano
parent
9b71efd014
commit
2ede073fd2
@ -787,6 +787,17 @@ static int refresh(struct refresh_params *o, unsigned int flag)
|
||||
setup_work_tree();
|
||||
read_cache();
|
||||
*o->has_errors |= refresh_cache(o->flags | flag);
|
||||
if (has_racy_timestamp(&the_index)) {
|
||||
/*
|
||||
* Even if nothing else has changed, updating the file
|
||||
* increases the chance that racy timestamps become
|
||||
* non-racy, helping future run-time performance.
|
||||
* We do that even in case of "errors" returned by
|
||||
* refresh_cache() as these are no actual errors.
|
||||
* cmd_status() does the same.
|
||||
*/
|
||||
active_cache_changed |= SOMETHING_CHANGED;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user