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

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

0 голосов
/ 08 февраля 2019

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

Вариант использования в моем репо:
  • все текстовые файлы должны иметь 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 isрассматривается как измененный, даже если он все еще имеет CRLF как eol
Test 2
  • новый репозиторий с 2 ​​.txt файлами (LF.txt и CRLF.txt)
    • LF.txt: eol = LF
    • CRLF.txt: eol = CRLF
  • добавить, зафиксировать, нажать
  • добавить.gitattributes (с содержанием, описанным выше): git add --renormalize .
    • CRLF.txt рассматривается как измененный и поэтапный (но нет различий в содержимом, и eol все еще CRLF)
    • .gitattributes яs все еще не отслежен
  • дорожка .gitattributes: git add .
  • зафиксировать и нажать
  • свежий клон репо
    • LF.txt: eol теперь CRLF (как и ожидалось)
    • 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, чтобы избежать изменения файлов после свежего клона?

1 Ответ

0 голосов
/ 08 февраля 2019

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

Да.

...