Re: Committing crimes with NTFS-3G

[Junio C Hamano <gitster@pobox.com>]

Johannes Sixt <j6t@kdbg.org> writes:

> Am 29.08.24 um 22:43 schrieb Roman Sandu:
>> To diagnose the problem, I ran git status with GIT_TRACE_PERFORMANCE
>> enabled, and what I see is that the "refresh index" region is taking up
>> 99% of the time.
>
> Of course. The stat information that Git on Linux caches in the index is
> vastly different from that that Git for Windows caches. So every time
> you switch OS, all files appear modified to Git.
>
> I suggest that you don't switch OS on a whim and take the 8 seconds
> delay once when you have to.

I somehow got an impression that the hit is not just that we need to
adjust cached lstat information in the index file once to the new
filesystem implementation after an OS switch, but every time (as if
we are forced to be extra careful and rehash every time until the
things improve, somewhat like how we handle the racy-Git situation).
Timestamps given by these OSes are not consistent and the clock
appears to have rewound, or something?

Timestamps of files in the working tree ordinarily should match
timestamps in the cached lstat information of these paths in the
index, and timestamp of the index file itself should be newer than
any of the above, or the recy-Git prevention code may tell us to
play safe.

I do not do Windows and/or NTFS, but I have to wonder if the smudge
filters (including the EOL conversion) play a role in this situation
as the working tree is getting switched between LF-native and
CRLF-native systems.  May there be situations where the system must
spend time only to realize that there is nothing it needs to do to
canonicalize the file contents and there is no modifications between
the HEAD commit, the index, and the working tree files, or something
silly like that?

Thanks.