Johannes Sixt <j6t@xxxxxxxx> 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.
