Re: Committing crimes with NTFS-3G

["Torsten Bögershausen" <tboegi@web.de>]

On Fri, Aug 30, 2024 at 09:28:17AM -0700, Junio C Hamano wrote:
> 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?

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 ?