Subject: Re: [PATCH v2] mv: refresh stat info for moved entry

From: Junio C Hamano <[email-masked]>
Date: Tue, 29 Mar 2022 09:44:34 -0700

Derrick Stolee <[email-masked]> writes:

>> Note that the test added in 't7001-mv.sh' requires a "sleep 1" to ensure the
>> 'ctime' of the file creation will be definitively older than the 'ctime' of
>> the renamed file in 'git mv'.
>
> Unfortunate that this is necessary, but it seems to be the only way
> to handle this because of the interaction with the system clock and
> the filesystem. There are several sleeps like this in
> t1701-racy-split-index.sh, for example.

Does "test-tool chmtime" to tweak the filesystem timestamp help?  I
didn't look at the specific step that uses sleep to work around.

>> +
>> +	/*
>> +	 * Refresh the new index entry. Using 'refresh_cache_entry' ensures
>> +	 * we only update stat info if the entry is otherwise up-to-date (i.e.,
>> +	 * the contents/mode haven't changed). This ensures that we reflect the
>> +	 * 'ctime' of the rename in the index without (incorrectly) updating
>> +	 * the cached stat info to reflect unstaged changes on disk.
>> +	 */
>> +	refreshed = refresh_cache_entry(istate, new_entry, CE_MATCH_REFRESH);
>> +	if (refreshed && refreshed != new_entry) {
>> +		add_index_entry(istate, refreshed, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
>> +		discard_cache_entry(new_entry);
>
> I'm glad you're checking that both refreshed is non-NULL and not equal
> to new_entry. Both are possible results from refresh_cache_entry().

;-)