From: Martin Date: Mon, 26 Jul 2021 10:31:37 GMT Subject: Re: Files modified, even after: git reset --hard Message-ID: In-Reply-To: On 26/07/2021 04:59, Chris Torek wrote: > On Sun, Jul 25, 2021 at 6:34 PM Martin 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.