The stat output for a random file in the root of the repository is as
follows:
```
File: <CENSORED>
Size: 91876 Blocks: 184 IO Block: 4096 regular file
Device: 259,2 Inode: 4630629 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/romasandu) Gid: ( 1000/romasandu)
Access: 2024-08-29 17:41:04.855126300 +0300
Modify: 2024-08-29 17:41:04.855609000 +0300
Change: 2024-08-29 17:41:04.855609000 +0300
Birth: -
```
Maybe lack of a birth stat is what drives git crazy?
My git version is 2.43.0, which is the one from the Ubuntu 24.04 repo.
Neither `core.trustctime` nor `core.checkStat minimal` (nor a
combination of them) help.
On 8/30/24 18:02, brian m. carlson wrote:
On 2024-08-30 at 12:52:05, Roman Sandu wrote:
Yes, I am aware that the index will be fully refreshed on the first run of
status. That is completely acceptable. But that is not what I am observing,
it is being refreshed on every single run of `git status`!
After running stat before and after a status, the sha256 is identical. Both
for files and for folders. Maybe Windows has somehow corrupted the index
with its negative aura which makes git invalidate it on every single run?
Are there tools in git to diagnose the reason for the index's cache being
invalidated?
It would still be helpful to see the output of the `stat` command, since
that would tell us useful things about what's causing Git to think the
data has changed. For example, some systems lack certain timestamp
granularity, which can break Git when compiled in certain ways.
You can see if setting `core.trustctime` to false fixes it, and you can
also try `core.checkStat` to `minimal` as well. You should try them in
that order to see if they fix things.
Also, what version of Git are you using? Is it the one in Ubuntu 24.04,
or the one from the git-core PPA, or a different one?
