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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 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 остаются без изменений.

Answer 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 ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

В приведенной выше табличной информации символ * подчеркивает различия между Windows и Unix. Ниже приведена информация о CLRF для платформ ОС:

---

Для пользователей Windows

• Если пользователи Windows работают с кроссплатформенными проектами, It ДОЛЖЕН быть core.autocrlf=true для машин Windows и core.autocrlf=input для машин Unix.
• Если пользователи Windows работают только с проектами Windows, это может быть core.autocrlf=true или core.autocrlf=false. Но core.autocrlf=input приведет к проблемам в этом случае.

---

Для пользователей Unix (Linux / Mac OS)

• Если пользователи Unix работают с кроссплатформенными проектами, это ДОЛЖНО быть core.autocrlf=true для компьютеров с Windows и core.autocrlf=input для компьютеров с Unix.
• Если пользователи Unix работают только с проектами Unix, это может быть core.autocrlf=input или core.autocrlf=false. Но core.autocrlf=true приведет к проблемам в этом случае.

---

Для тех же пользователей ОС

• Для чистого проекта Windows или чистого проекта Unix это может быть core.autocrlf=false.