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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux