Derrick Stolee <derrickstolee@xxxxxxxxxx> 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().
;-)
