Why are files seen as modified after fresh clone? When is git add --renormalize . used?

问题

I have a problem with files which are seen as modified after a fresh git clone.

Usecase in my repo:

• all text files shall have eol=LF, except *.txt files which shall have eol=CRLF.
  

Here's how .gitattributes looks like:

*       text=auto
*.txt   text  eol=crlf
*.png binary
*.jpg binary
*.bmp binary

Here's my tests:

Test 1

• new repo with 2 .txt files (LF.txt and CRLF.txt)
  • LF.txt: eol=LF (end of line is LF in the whole file)
  • CRLF.txt: eol=CRLF (end of line is CRLF in the whole file)
• add, commit, push
• add .gitattributes (with the content described above): git add .gitattributes, commit, push
• fresh clone of repo
  • LF.txt: eol is now CRLF (as expected)
  • CRLF.txt is seen as modified, even if it still has CRLF as eol

Test 2

• new repo with 2 .txt files (LF.txt and CRLF.txt)
  • LF.txt: eol=LF
  • CRLF.txt: eol=CRLF
• add, commit, push
• add .gitattributes (with the content described above): git add --renormalize .
  • CRLF.txt is seen as modified and staged (but there are no content differences and eol is still CRLF)
  • .gitattributes is still untracked
• track .gitattributes: git add .
• commit and push
• fresh clone of repo
  • LF.txt: eol is now CRLF (as expected)
  • CRLF.txt: eol is CRLF (as in the beginning)
  • repo is clean

Additional info

• OS: Windows 10
• git version: 2.20.1.windows.1

Questions

1. Test 1: why is CRLF.txt seen as modified after a fresh clone?
2. Test 2: what is git add --renormalize . actually doing? Why doesn't it stage .gitattributes also?
3. When setting up .gitattributes in a repo which already has some history, is it recommended to run git add --renormalize in order to avoid modified files after fresh clone?

回答1:

Test 1: why is CRLF.txt seen as modified after a fresh clone?

Because you've lied to git: you've told git that the line endings for CRLF.txt in your repository are Unix-style (LF) line endings, but that you want Windows-style (CRLF) line endings in your working folder. That's what the text attribute means: normalize the line endings, so that they have Unix-style line endings in the repository.

But your first step was to add the file with Windows-style line endings into the repository.

So, git can look at the file on-disk, convert its Windows-style (CRLF) line endings to the normal form (Unix-style LF line endings), and compare the results to what's in the repository.

Those contents don't match. Thus, it thinks you've modified the file. That is why you renormalize files.

Test 2: what is git add --renormalize . actually doing?

It updates the files to match what you've claimed in .gitattributes. When you add a .gitattributes, you aren't changing the contents of the files on-disk or in the repository. But you may be (and in this case are) changing the claims you're making about the way the contents exist in the repository.

If the contents in the repository aren't actually what you claimed, then git add --renormalize will correct that.

Why doesn't it stage .gitattributes also?

Renormalization only affects files already in the repository, it applies "the 'clean' process freshly to all tracked files to forcibly add them again to the index." (From the git documentation; emphasis mine.)

So it truly only renormalizes existing content.

When setting up .gitattributes in a repo which already has some history, is it recommended to run git add --renormalize in order to avoid modified files after fresh clone?

Yes.

来源：https://stackoverflow.com/questions/54592361/why-are-files-seen-as-modified-after-fresh-clone-when-is-git-add-renormalize