Re: Files modified, even after: git reset --hard

On 26/07/2021 04:59, Chris Torek wrote:

On Sun, Jul 25, 2021 at 6:34 PM Martin [off-list ref] wrote:

quoted

Actually there is something else.

If a file has line-endings that will change, then
     git add --renormalize .
     git commit -m foo
will commit those files.

But I am now also getting files, that show modified, but that can not be
committed renormalized (0 lines changed).

I believe (but can't demonstrate) that this is a temporary condition.

I now found one, that does not seem temporary at all...

git remote -v
gh-me   https://github.com/User4martin/binutils-gdb.git (fetch)
gh-me   https://github.com/User4martin/binutils-gdb.git (push)
gh-redprig      https://github.com/red-prig/binutils-gdb.git (fetch)
gh-redprig      https://github.com/red-prig/binutils-gdb.git (push)
origin  git://sourceware.org/git/binutils-gdb.git (fetch)
origin  git://sourceware.org/git/binutils-gdb.git (push)

fsck had some dangling commits, I did a "git gc --aggressive".
Now
  git fsck
Checking object directories: 100% (256/256), done.
Checking objects: 100% (1062929/1062929), done.
Checking connectivity: 1062929, done.

Switching to a far away commit
git switch -f --detach master
git rev-list master | wc -l
93917

git status shows no modified files


Then switching to  (this is on master branch)
git switch -f --detach a362ee23634
git rev-list a362ee23634 | wc -l
4164

git status --porcelain=v2
1 .M N... 100644 100644 100644 9e677a52ae690808165993a0f3f17ac49e3969df 
9e677a52ae690808165993a0f3f17ac49e3969df bfd/Makefile.dos
1 .M N... 100644 100644 100644 ff24f19c0b6e0c7fb713c79e8f1765bc22fe7adc 
ff24f19c0b6e0c7fb713c79e8f1765bc22fe7adc binutils/Makefile.dos
1 .M N... 100644 100644 100644 1d9541c2f896842d1bafe68ccf0a51e291d66688 
1d9541c2f896842d1bafe68ccf0a51e291d66688 gas/Makefile.dos
1 .M N... 100644 100644 100644 57fab985680ea151379069abe414bcb590cdd743 
57fab985680ea151379069abe414bcb590cdd743 ld/Makefile.dos


git reset --hard
makes no difference.

Only
     git diff
shows actual textual differences
e.g.

  TARGETLIB = libbfd.a
-CFLAGS = -g -O $(HDEFINES) $(TDEFINES) $(CSEARCH) $(CSWITCHES) # 
-DINTEL960VERSION
+CFLAGS = $(MINUS_G) $(HDEFINES) $(TDEFINES) $(CSEARCH) $(CSWITCHES) # 
-DINTEL960VERSION

Git has a number of cheats to make `git status` and other ops fast.
These cheats *assume* that the committed files, the index copies
of files, and the working tree copies of files all agree in terms of
line endings as coordinated through `core.autocrlf` and `.gitattributes`
settings.

When they *don't* agree, you get phantom differences.  Running
commands like `git diff` show no differences because of these
phantom states.  Eventually this clears up on its own when the
cheats really *do* agree with the settings.  Changing the settings
is what disturbs the cheats.

Git can't do much with `core.autocrlf`, but if it noticed that a
`.gitattributes` file was very recent, and turned off the shortcuts
and did the slower full status checks, updates via `.gitattributes`
would not show phantom changes.  The drawback is that updates
to `.gitattributes` could make `git status` very slow.

Ok, one of the repros has had its .gitattributes committed on the root 
commit, and never changed.
Neither do/did I change the config since it was created.

My question is are there any plumbing commands, that could allow me to 
look further at it.