Git add --renormalize не выполняет повторную проверку моих файлов с правильными окончаниями строк

TLDR:

Эти конфигурации должны работать для вас в Linux и Windows (если вы не работаете с технологией, специфичной для Windows):

git config --global core.autocrlf false
git config --global core.eol lf

После того, как вы это сделаете, вам нужно заставить Git выполнить извлечение файла, который должен иметь LF в вашем рабочем каталоге. Один из способов сделать это — удалить его из рабочего каталога, а затем выполнить извлечение:

rm myfolder/myfile.txt
git checkout HEAD -- myfolder/myfile.txt

Если у вас есть core.autocrlf = true и для вашего файла установлен атрибут text (напрямую или через text=auto без указания атрибута eol), вы всегда будете получать CRLF для этого файла в своем рабочем каталоге при выполнении проверки.

Это имеет смысл с точки зрения имени «autocrlf», поскольку оно предназначено для автоматического преобразования CRLF при оформлении заказа для разработчиков Windows, но также обеспечивает преобразование любых новых файлов в LF при регистрации, чтобы разработчики Windows не вводили LF в репозиторий.

Ваша текущая конфигурация для извлечения текстовых файлов отмечена красным на следующей диаграмме.

Основываясь на предоставленной вами информации, я предполагаю, что окончание строки myfolder/myfile.txt внутри репозитория git уже LF, что объясняет, почему вы не видите никаких изменений, когда видите git status.

Теперь, если вы хотите исправить это и извлечь файл как LF, вы можете просто переключить autocrlf на false:

git config --global core.autocrlf false

Это поставит вас в ситуацию, отмеченную зеленым:

Что касается значения core.eol, у вас есть два основных варианта:

1. Оставьте это значение неопределенным, что эквивалентно наличию git config --global core.eol native

Или (на мой взгляд, даже лучше):

2. git config --global core.eol lf

Если вы выберете вариант 2, все файлы, хранящиеся с LF в репозитории, сохранят свои LF при извлечении, даже когда вы загружаетесь в Windows. Учитывая, что все современные программы Windows могут работать с LF, это не должно быть проблемой, и вы не столкнетесь с какими-либо проблемами, связанными с CRLF, вызывающими проблемы в ваших Docker-контейнерах.

Если вы работаете с технологиями, специфичными для Windows, вы всегда можете добавить определенные записи в свой файл .gitattributes, чтобы избежать наличия расширений LF, специфичных для Windows.

Например:

# INI file extension
*.[iI][nN][iI]              text eol=crlf

# Batch scripts (cmd, bat)
*.[cC][mM][dD]              text eol=crlf
*.[bB][aA][tT]              text eol=crlf

Заключительный этап

Однажды ты все это сделал. Затем вам нужно заставить Git выполнить извлечение файлов, которые должны иметь LF в вашем рабочем каталоге. Один из способов сделать это — удалить его из рабочего каталога, а затем выполнить извлечение:

rm myfolder/myfile.txt
git checkout HEAD -- myfolder/myfile.txt

Другой способ сделать это — удалить его из рабочего каталога (и индекса), а затем выполнить сброс:

git rm myfolder/myfile.txt
git reset --hard

Диаграмма, использованная в этом ответе, во многом вдохновлена ​​этого ответа с некоторыми улучшениями, основанными на внимательном прочтении документации и скрипте PowerShell для изучения различных сценариев. Полная версия доступна здесь.

См. также статью git's autocrlf=true считается вредным | markentier.tech

Обновления диаграммы:

• Включение атрибута eol в часть checkout диаграммы делает ее более полной, поскольку eol, указанный в файле .gitattributes, имеет приоритет над core.autocrlf.