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

On Sun, Jul 25, 2021 at 11:43 AM Martin [off-list ref] wrote:

quoted

quoted

quoted

[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