On Fri, Aug 30, 2024 at 09:28:17AM -0700, Junio C Hamano wrote: > 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? Now, that make me wonder: What are the settings for core.autocrlf ? Is there a .gitattributes file ? According to my experience there should be one, when working cross-platform. A version with the single line * text=auto works for many projects, and may be fine-tuned to what you need. The questin about core.filemode has been raised elsewhere, it should be false for this repo (but probably is). Now back to the lstat() question: There is a git ls-files --debug which may give more insight about what is going on. And back to the line-endings: does git ls-files --eol give any hints, may be ?
