On 26/07/2021 04:59, Chris Torek wrote:
On Sun, Jul 25, 2021 at 6:34 PM Martin <git@xxxxxxxxxx> wrote:
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.
