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. 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
