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

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

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

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

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

67
core.autocrlf git linux newline windows

3 ответов

три значения:autocrlf:

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

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

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

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

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

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

94

я исследовал 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 на всех платформах. В этом случае, если ГИТ лица CRLF он неявно преобразует его в LF, и существующие файлы LF остается как есть.

9

к твоему сведению. По умолчанию строка, заканчивающаяся в 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. Но!--2--> приведет к проблемам в этом случае.

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

  • если пользователи Unix работают с кросс-платформенными проектами, это должны быть core.autocrlf=true для машин Windows и core.autocrlf=input для Unix машины.
  • если пользователи Unix работают только с проектами Unix, это может быть как core.autocrlf=input или core.autocrlf=false. Но!--1--> приведет к проблемам в этом случае.

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

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