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

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

Usecase in my repo:
  • все текстовые файлы должны содержать eol=LF, за исключением файлов *.txt, в которых должно быть eol=CRLF.

Вот как выглядит .gitattributes: 

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

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

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 (конец строки - CRLF во всем файле)
  • добавить, зафиксировать, нажать
  • добавить .gitattributes (с описанным выше содержанием): git add .gitattributes, зафиксировать, нажать
  • fresh clone of repo
    • LF.txt: eol is now CRLF (as expected)
    • CRLF.txt считается измененным, даже если CRLF все еще имеет значение eol
Test 2
  • new repo with 2 .txt files (LF.txt and CRLF.txt)
    • LF.txt: eol=LF
    • CRLF.txt: eol = CRLF
  • добавить, зафиксировать, нажать
  • 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 все еще не отслеживается
  • трек .gitattributes: git add .
  • совершить и подтолкнуть
  • fresh clone of repo
    • LF.txt: eol is now CRLF (as expected)
    • CRLF.txt: eol CRLF (как в начале)
    • репо чистое

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

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

Вопросов

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

git eol gitattributes
person nicole    schedule 08.02.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Тест 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, чтобы избежать изменения файлов после нового клонирования?

да.

person Edward Thomson    schedule 08.02.2019