Re: [PATCH v2] mv: refresh stat info for moved entry
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 29, 2022, 16:44 UTC
- Message-ID
- <xmqqa6d8wvwt.fsf@gitster.g>
- In-Reply-To
- <5ca04e86-6c61-3d4e-88a0-a3c827e19e13@github.com>
Derrick Stolee <derrickstolee@github.com> writes:
Show 8 quoted lines
>> 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.
Show 15 quoted lines
>> +
>> + /*
>> + * 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().;-)