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

From: Chris Torek <chris.torek@gmail.com>
Date: Jul 26, 2021, 00:33 UTC
Message-ID: <CAPx1GvcHiaGsuOybOijRYpmivO0dLvUFacAeOrM4DfY-uuXB2Q@mail.gmail.com>
In-Reply-To: <bfc257c7-bf74-06be-ac62-9a6d27f565c9@mfriebe.de>

On Sun, Jul 25, 2021 at 11:43 AM Martin <git@mfriebe.de> wrote:

Show 5 quoted lines

>>>> [Files show up as every-line-modified]
>> [and] git replace has a weird effect.
> Ok, it seem that
>    git switch
> simple did not update the file.

Here's what's going on.

(1) No *committed* object, including committed file data, can ever
    be changed.

(2) Someone actually committed some files with some sort of line
    endings.

(Points 1 and 2 are true regardless of anything else.)

If you never have Git mess with line endings at all, neither of these two points make any difference. But you chose to start asking Git to mess with line endings. Things now depend on exactly *what* you ask Git to *do* about these line endings.

Let's suppose, just for convenience for now, that the files in the repository right now actually do have CRLF line endings.

Let's suppose further that you ask that Git ensure that your *working tree* copies of each file contain CRLF line endings.

This means that existing *committed* copies of files already have the ending you prefer. But now that you have started to ask Git to *mess with your line endings* -- by asking that your *working tree* copies have CRLF endings -- Git will now begin making sure that *future committed copies of files* have LF-only line endings.

What this means is that any existing commit you check out has the "wrong" line endings! You've just told Git that all the *committed* files should have LF-only line endings.

You might ask why "ensure my working tree copies have CRLF line endings" means "ensure all future committed files have LF-only line endings". That's a valid design question. But it is the case.

As for "git replace", you've figured the rest out already: if you use git replace to make Git use new, LF-only line ending objects (file data), Git is now happy about the internal storage. It just takes some shuffling-about to cause these replaced objects to wind up in Git's *index* AKA *staging area*.

I'll mostly stop here, because this explains the results you have so far, but in general, setting `core.autocrlf` tends to be inferior to making explicit decisions about particular files via `.gitatttributes` files.

Chris