Git в Windows: что означают настройки crlf?

Я не понимаю сложности, связанные с настройками CrLf в git: core.autocrlf, core.safecrlf

Я разрабатываю кросс-платформенный проект в команде и хотел бы, чтобы разработчики Windows и Linux могли работать вместе без git маркировки файлов как измененные только из-за стиля окончания строки.

Что означают различные настройки? Каковы были бы последствия выбора любого из вариантов? И что было бы лучшим решением для моего случая?

Да, я знаю этот вопрос, и ответы там не были проницательными, поэтому это не помогло.

Ответы

Ответ 1

Три значения для autocrlf:

  • true - когда контент отправляется в репозиторий (он зафиксирован), его окончания строк будут преобразованы в LF, а когда контент выходит из репозитория (вычеркнуто), окончания строк преобразуются в CRLF. Это, в общем, предназначено для незнакомых пользователей/редакторов Windows. Учитывая предположение, что редактор (или пользователь) собирается создавать файлы с окончанием CRLF и будет волноваться, если он увидит нормальные окончания LF, но вы хотите, чтобы LF-окончания в репо, это, надеюсь, вас охватит. Тем не менее, возможно, что все идет вразрез. В связанных вопросах есть примеры конфликтов ложных слияний и отчетов об измененных файлах.

  • input - когда содержимое входит в репозиторий, его окончания строк будут преобразованы в LF, но контент остается нетронутым на выходе. Это в основном в той же сфере, что и true, при условии, что редакторы действительно могут иметь дело с окончаниями LF правильно; вы просто предостерегаете от возможности случайного создания файла с окончанием CRLF.

  • false - git вообще не касается окончаний строк. Это вам. Это то, что многие рекомендуют. С этим параметром, если окончание строк в файлах будет запущено, вы должны будете знать об этом, поэтому конфликты слияния намного реже (предполагая информированных пользователей). Обучение разработчиков тому, как использовать их редакторы /IDE, может в значительной степени позаботиться о проблеме. Все редакторы, которые я видел для программистов, могут справиться с этим, если они настроены правильно.

Обратите внимание, что autocrlf не будет влиять на контент, который уже находится в репозитории. Если вы уже что-то сделали с окончанием CRLF, они останутся такими. Это очень хорошая причина, чтобы избежать зависимости от autocrlf; если один пользователь не установил его, они могут получить контент с концами CRLF в репо, и он будет придерживаться. Более сильный способ принудительной нормализации заключается в атрибуте ; установив его на auto для заданного пути, он помечает его для нормализации конца строки, предполагая, что git решает, что контент является текстовым (не двоичным).

Связанная опция safecrlf, которая в основном является способом убедиться, что вы не выполняете необработанное преобразование CRLF в двоичном файле.

У меня нет большого опыта работы с проблемами Windows и git, поэтому обратная связь о проблемах/ошибках, безусловно, приветствуется.

Ответ 2

Я изучил 3 возможных значения для случаев фиксации и проверки, и это результирующая таблица:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Я бы рекомендовал использовать core.autocrlf = input во всех платформах. В этом случае, если Git сталкивается с CRLF он будет неявно преобразовывать его в LF, а существующие файлы с LF остаются как есть.

Ответ 3

FYI. По умолчанию, строка, заканчивающаяся в Windows, заставит CRLF и Linux взять LF. Пожалуйста, найдите нижеприведенную таблицу для четкого понимания.

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║    false     ║    input     ║    true      ║
║               ║ Win => Unix  ║ Win => Unix  ║ Win => Unix  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ *CRLF => LF  ║ *CRLF => LF  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ *LF => CRLF  ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Ответ 4

Я получаю эту ошибку: у файла будет исходный конец строки в вашем рабочем каталоге. предупреждение: LF будет заменен CRLF на DV/debug.log. а затем "фатальный: сбой файлов не удалось"