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

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



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



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



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

627   3  

3 ответов:

три значения: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, поэтому обратная связь о последствиях / подводных камнях, безусловно, приветствуется.

94  
2011-12-14 12:23:21

я исследовал 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 faces CRLF он неявно преобразует его в LF, и существующие файлы LF остается как есть.

9  
2018-07-31 18:56:07

к вашему сведению. По умолчанию строка, заканчивающаяся в 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.
2  
2017-07-04 02:04:01

Comments

    Ничего не найдено.
Click here to cancel reply.