On Fri, Aug 30, 2024 at 09:28:17AM -0700, Junio C Hamano wrote:

Johannes Sixt [off-list ref] writes:

quoted

Am 29.08.24 um 22:43 schrieb Roman Sandu:

quoted

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 ?