Почему файлы считаются измененными после свежего клона? Когда есть git add --renormalize . используемый?

Question

У меня проблема с файлами, которые рассматриваются как измененные после свежего клона git.

Usecase в моем репо:

• все текстовые файлы должны иметь eol=LF, Кроме *.txt файлы, которые должны иметь eol=CRLF,
  

Вот как .gitattributes похоже:

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

Вот мои тесты:

Тест 1

• новый репо с 2 .txt файлами (LF.txt и CRLF.txt)
  • LF.txt: eol = LF (конец строки LF во всем файле)
  • CRLF.txt: eol = CRLF (конец строки CRLF во всем файле)
• добавить, зафиксировать, нажать
• добавлять .gitattributes (с содержанием, описанным выше): git add .gitattributes, совершить, нажать
• свежий клон репо
  • LF.txt: eol сейчас CRLF (как и ожидалось)
  • CRLF.txt считается измененным, даже если он все еще CRLF как eol

Тест 2

• новый репо с 2 .txt файлами (LF.txt и CRLF.txt)
  • LF.txt: eol = LF
  • CRLF.txt: eol = CRLF
• добавить, зафиксировать, нажать
• добавлять .gitattributes (с содержанием, описанным выше): git add --renormalize .
  • CRLF.txt рассматривается как измененный и поэтапный (но нет никаких различий в содержании, и eol все еще CRLF)
  • .gitattributes все еще не прослежен
• трек .gitattributes: git add .
• совершить и подтолкнуть
• свежий клон репо
  • LF.txt: eol сейчас CRLF (как и ожидалось)
  • CRLF.txt: eol is CRLF (как в начале)
  • репо чисто

Дополнительная информация

• ОС: Windows 10
• версия git: 2.20.1.windows.1

Вопросы

1. Тест 1: почему CRLF.txt видится модифицированным после свежего клона?
2. Тест 2: что такое git add --renormalize . на самом деле делать? Почему не ставить .gitattributes также?
3. При настройке .gitattributes в репо, который уже имеет некоторую историю, рекомендуется запустить git add --renormalize во избежание изменения файлов после свежего клона?

Answer 1

Тест 1: почему CRLF.txt видится модифицированным после свежего клона?

Потому что ты солгал git: ты сказал git, что конец строки для CRLF.txt в вашем репозитории есть окончания строк в стиле Unix (LF), но вы хотите, чтобы в рабочей папке были окончания строк в стиле Windows (CRLF). Вот чтоtextАтрибут означает: нормализовать окончания строк, чтобы они имели окончания строк в стиле Unix в хранилище.

Нопервым шагом было добавление файла с окончаниями строк в стиле Windows в хранилище.

Таким образом, git может просмотреть файл на диске, преобразовать его окончания строк в стиле Windows (CRLF) в обычную форму (окончания строк LF в стиле Unix) и сравнить результаты с тем, что находится в хранилище.

Это содержимое не совпадает. Таким образом, он думает, что вы изменили файл.Вот почему вы перенормируете файлы.

Тест 2: что такое git add --renormalize . на самом деле делать?

Он обновляет файлы, чтобы соответствовать тому, что вы заявили в .gitattributes, Когда вы добавляете.gitattributes Вы не меняете содержимое файлов на диске или в хранилище. Но вы можете(и в данном случае) изменяете свои утверждения о том, как содержимое существует в хранилище.

Если содержимое репозитория не соответствует действительности, о котором вы заявляли, тогда git add --renormalize исправлю это.

Почему он также не ставит.gitattributes?

Перенормировка влияет только на файлы, уже находящиеся в хранилище, она применяет процесс "очистки" заново ко всем отслеживаемым файлам, чтобы принудительно добавить их снова в индекс ". (Из документации git; выделение мое.)

Так что это действительно только перенормирует существующий контент.

При настройке.gitattributes в репо, который уже имеет некоторую историю, рекомендуется запускать git add --renormalize, чтобы избежать изменения файлов после свежего клона?

Да.