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

From: Chris Torek <chris.torek@gmail.com>
Date: Jul 26, 2021, 02:59 UTC
Message-ID: <CAPx1GvdM7CzsbT1SWW9+OPcG9FL7WXQ7YD6aM7P0krujp_OrkQ@mail.gmail.com>
In-Reply-To: <070f7f5e-0e6c-2edc-1403-9265c810df17@mfriebe.de>

On Sun, Jul 25, 2021 at 6:34 PM Martin <git@mfriebe.de> wrote:

Show 9 quoted lines

> 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