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

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

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

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

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

Источник

3 ответа

Решение

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

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

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

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

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

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

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

Источник

Я исследовал 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 оставайся как есть.

Источник

К вашему сведению. По умолчанию конец строки в 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 работают с кроссплатформенными проектами, это ДОЛЖНО быть 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,
Источник
Другие вопросы по тегам