Re: Committing crimes with NTFS-3G

> 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?