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

[Chris Torek <chris.torek@gmail.com>]

On Sun, Jul 25, 2021 at 6:34 PM Martin <git@mfriebe.de> 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.

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.

Overall this isn't normally a big problem.  It only affects one person
at a time, when they change these settings, and then it clears up
over time...

Chris