Как преобразование окончания строки работает с git core.autocrlf между разными операционными системами

Лучшее объяснение того, как работает core.autocrlf, можно найти в человеке gitattributes страницу в разделе text attribute.

Вот как выглядит core.autocrlf в настоящее время (или, по крайней мере, с версии 1.7.2, насколько мне известно):

• core.autocrlf = true

1. Извлеченные из репозитория текстовые файлы, содержащие только LF символов, нормализуются до CRLF в вашем рабочем дереве; файлы, содержащие CRLF в репозитории, не будут затронуты
2. Текстовые файлы, которые содержат только LF символов в репозитории, нормализуются с CRLF до LF при фиксации обратно в репозиторий. Файлы, содержащие CRLF в репозитории, будут зафиксированы без изменений.

• core.autocrlf = input

1. Текстовые файлы, извлеченные из репозитория, сохранят исходные символы EOL в вашем рабочем дереве.
2. Текстовые файлы в вашем рабочем дереве, содержащие CRLF символов, нормализуются до LF при сохранении обратно в репозиторий.

• core.autocrlf = false

1. core.eol определяет символы EOL в текстовых файлах вашего рабочего дерева.
2. core.eol = native по умолчанию, что означает, что EOL Windows CRLF и * nix EOL LF в рабочих деревьях.
3. Настройки репозитория gitattributes определяют нормализацию символов EOL для коммитов в репозиторий (по умолчанию нормализация до LF символов).

Я только недавно исследовал эту проблему, и я также считаю, что ситуация очень запутанная. Параметр core.eol определенно помог прояснить, как символы EOL обрабатываются git.

Проблема EOL в проектах со смешанной платформой долгое время делала мою жизнь невыносимой. Проблемы обычно возникают, когда в репозитории уже есть файлы с разными и смешанными EOL уже. Это означает, что:

1. В репо могут быть разные файлы с разными EOL.
2. Некоторые файлы в репо могут иметь смешанные EOL, например комбинация CRLF и LF в одном файле.

Вопрос не в том, как это происходит, но это происходит.

Я провел несколько тестов преобразования в Windows для различных режимов и их комбинаций.
Вот что я получил в слегка измененной таблице:

                 | Resulting conversion when       | Resulting conversion when 
                 | committing files with various   | checking out FROM repo - 
                 | EOLs INTO repo and              | with mixed files in it and
                 |  core.autocrlf value:           | core.autocrlf value:           
--------------------------------------------------------------------------------
File             | true       | input      | false | true       | input | false
--------------------------------------------------------------------------------
Windows-CRLF     | CRLF -> LF | CRLF -> LF | as-is | as-is      | as-is | as-is
Unix -LF         | as-is      | as-is      | as-is | LF -> CRLF | as-is | as-is
Mac  -CR         | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF    | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF+CR | as-is      | as-is      | as-is | as-is      | as-is | as-is

Как видите, есть 2 случая, когда преобразование происходит при фиксации (3 левых столбца). В остальных случаях файлы фиксируются как есть.

При оформлении заказа (3 правых столбца) существует только 1 случай, когда преобразование происходит, когда:

1. core.autocrlf равно true и
2. файл в репо имеет LF EOL.

Самое удивительное для меня, и я подозреваю, что причина многих проблем EOL заключается в том, что нет конфигурации, в которой смешанные EOL, такие как _6 _ + _ 7_, нормализуются.

Также обратите внимание, что "старые" Mac EOL только CR также никогда не конвертируются.
Это означает, что если плохо написанный скрипт преобразования EOL пытается преобразовать смешанный конечный файл с CRLFs + LFs, просто преобразовав LFs в CRLFs, тогда он оставит файл в смешанном режиме с "lonely" CRs, где CRLF был преобразован в CRCRLF.
Git не будет преобразовывать ничего, даже в режиме true, и опустошение EOL продолжается. Это на самом деле случилось со мной и очень сильно испортило мои файлы, поскольку некоторые редакторы и компиляторы (например, VS2010) не любят Mac EOL.

Я думаю, единственный способ справиться с этими проблемами - это иногда нормализовать все репо, проверяя все файлы в режиме input или false, выполняя правильную нормализацию и повторно фиксируя измененные файлы (если таковые имеются ). В Windows предположительно возобновить работу с core.autocrlf true.

Значение core.autocrlf не зависит от типа ОС, но в Windows значение по умолчанию true, а в Linux - input. Я изучил 3 возможных значения для случаев фиксации и проверки, и вот итоговая таблица:

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

Скоро что-то изменится на фронте "преобразования eol" с выходом грядущего Git 1.7.2 < / а>:

Новый параметр конфигурации core.eol добавляется / развивается:

Это замена фиксации "Добавить переменную конфигурации" core.eol ", которая в настоящее время находится в pu (последняя в моей серии).
Вместо того, чтобы подразумевать, что" core.autocrlf=true "заменяет" * text=auto ", это ясно указывает, что autocrlf предназначен только для пользователей, которые хотят работать с CRLF в своем рабочем каталоге в репозитории, не имеющем нормализации текстовых файлов.
Когда он включен, "core.eol" имеет значение игнорируется.

Представьте новую переменную конфигурации "core.eol", которая позволяет пользователю устанавливать, какие окончания строк использовать для файлов с нормализацией конца строки в рабочем каталоге.
По умолчанию используется значение "native", что означает CRLF в Windows и LF везде. Обратите внимание, что "core.autocrlf" переопределяет core.eol.
Это означает, что:

[core]
  autocrlf = true

помещает CRLF в рабочий каталог, даже если для core.eol установлено значение «lf».

core.eol:

Устанавливает тип окончания строки, который будет использоваться в рабочем каталоге для файлов, для которых задано свойство text.
Альтернативными вариантами являются lf, crlf и native, в которых используется окончание строки платформы.
Значение по умолчанию значение native.

Другие изменения : рассматривается:

Для 1.8 я бы подумал о том, чтобы core.autocrlf просто включил нормализацию и оставил решение о завершении строки рабочего каталога на core.eol, но это нарушит настройки пользователей.

git 2.8 (март 2016 г.) улучшает способ core.autocrlf влияния на eol:

См. commit 817a0c7 (23 февраля 2016 г.), совершить 6e336a5, совершить df747b8, совершить df747b8 (10 февраля 2016 г.), зафиксировать df747b8, совершить df747b8 (10 февраля 2016 г.) и , совершить bb211b4, зафиксировать 92cce13, совершить 320d39c, зафиксировать 4b4024f, зафиксировать bb211b4, совершить 92cce13, совершить 320d39c (5 февраля 2016 г.), выполненный Торстеном Бёгерсхаузеном (tboegi).
^{(объединено Junio ​​C Hamano - gitster - в commit c6b94eb, 26 февраля 2016 г.)}

convert.c: рефакторинг crlf_action

Выполните рефакторинг определения и использования crlf_action.
Сегодня, когда для файла не установлен атрибут «crlf», crlf_action устанавливается на CRLF_GUESS. Вместо этого используйте CRLF_UNDEFINED и ищите "text" или "eol", как раньше.

Замените старое CRLF_GUESS использование:

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

Сделайте более ясным, что есть что, определив:

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

Поскольку torek добавляет в комментариях:

все эти переводы (любое преобразование EOL из настроек eol= или autocrlf и фильтров «clean») выполняются, когда файлы перемещаются из рабочего дерева в индекс, то есть во время git add, а не в git commit время.
(Обратите внимание, что git commit -a, --only или --include действительно добавляют файлы в индекс в это время.)

Для получения дополнительной информации см. «В чем разница между autocrlf и eol».

Вот мое понимание этого до сих пор, на случай, если это кому-то поможет.

core.autocrlf=true и core.safecrlf = true

У вас есть репозиторий, в котором все окончания строк одинаковы, но вы работаете на разных платформах. Git позаботится о том, чтобы концы ваших строк были преобразованы в значения по умолчанию для вашей платформы. Почему это важно? Допустим, вы создали новый файл. Текстовый редактор на вашей платформе будет использовать окончания строк по умолчанию. Когда вы регистрируете его, если для core.autocrlf не установлено значение true, вы ввели несоответствие окончания строки для кого-то на платформе, которая по умолчанию имеет другое окончание строки. Я всегда устанавливаю safecrlf, потому что мне хотелось бы знать, что операция crlf обратима. С этими двумя настройками git изменяет ваши файлы, но проверяет их обратимость.

core.autocrlf=false

У вас есть репозиторий, в котором уже зарегистрированы смешанные окончания строк, и исправление неправильных окончаний строк может привести к поломке других вещей. В этом случае лучше не указывать git преобразовывать окончания строк, потому что тогда это усугубит проблему, для решения которой он был разработан, - упрощая чтение различий и менее болезненное слияние. С этим параметром git не изменяет ваши файлы.

core.autocrlf=input

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

Нет, ответ @jmlane неверен.

Для Checkin (git add, git commit):

1. если свойство text равно Set, Set value to 'auto', преобразование происходит, когда файл был зафиксирован с помощью 'CRLF'
2. если свойство text равно Unset: ничего не происходит, enen для Checkout
3. if text property is Unspecified, conversion depends on core.autocrlf
   1. if autocrlf = input or autocrlf = true, the conversion only happens when the file in the repository is 'LF', if it has been 'CRLF', nothing will happens.
   2. если autocrlf = false, ничего не происходит

Для Checkout:

1. если свойство text равно Unset: ничего не происходит.
2. if text property is Set, Set value to 'auto: it depends on core.autocrlf, core.eol.
   1. core.autocrlf = input : nothing happens
   2. core.autocrlf = true: преобразование происходит только тогда, когда файл в репозитории имеет значение 'LF', 'LF' -> 'CRLF'
   3. core.autocrlf = false: преобразование происходит только тогда, когда файл в репозитории имеет значение 'LF', 'LF' -> core.eol
3. if text property is Unspecified, it depends on core.autocrlf.
   1. the same as 2.1
   2. то же, что 2.2
   3. Нет, ничего не происходит, core.eol не действует, если свойство text равно Unspecified

Поведение по умолчанию

Таким образом, поведение по умолчанию - text, свойство - Unspecified и core.autocrlf = false:

1. для проверки ничего не происходит
2. для оформления заказа ничего не происходит

Выводы

1. если установлено свойство text, поведение проверки зависит от него самого, а не от autocrlf
2. autocrlf или core.eol предназначены для проверки, а autocrlf> core.eol

Сделал несколько тестов как на Linux, так и на Windows. Я использую тестовый файл, содержащий строки, заканчивающиеся на LF, а также строки, заканчивающиеся на CRLF.
Файл зафиксирован, удален и затем извлечен. Значение core.autocrlf устанавливается перед фиксацией, а также перед оформлением заказа. Результат ниже.

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  

ЛМАО!

Вы, ребята, все неправильно поняли.

Утверждение core.autocrlf, которое true приводит к CRLF- ›LF при фиксации, явно неверно!
Это не так просто, понимаете ...
(Параметр соответствует text=auto в .gitattributes и core.eol установлен в crlf в git config; что именно означает? хахаха.)
Это означает, что (если для файла не установлен атрибут .gitattributes text, тогда core.autocrlf true означает, что) это зависит от того, фиксируется ли новый файл (в в этом случае, да, он будет нормализован до LF в базе данных репозитория git), или будет ли это существующий файл, который вы отредактировали и зафиксировали (в этом случае НИЧЕГО не произойдет; если --хахаха - вы не запустите git add --renormalize ., и в этом случае он будет нормализован в базе данных репозитория git).

Но честно: кого это волнует?

(Вы видите ... вышеупомянутый механизм, происходит только с файлом, для которого .gitattributes, не помещен вариант текстового атрибута: text, -text, text=auto.)

Вы действительно должны использовать .gitattributes с настройкой по умолчанию для всех ваших файлов, либо

* -text
# followed by specialization

установка по умолчанию всех (кроме специализаций) на "как есть" и полное переопределение core.autocrlf или использование значения по умолчанию

*  text=auto
# followed by specialization

это означает, что все файлы (кроме специализаций), которые git автоматически определяет как недвоичные (текстовые), имеющие LF в базе данных git [1 **], получают CRLF, когда core.autocrlf равно true, или когда core.eol равно crlf, или когда core.eol равно native (по умолчанию), и вы находитесь на платформе Windows. Иначе вы получите LF.

Какие специализации я имею в виду? Например, если .bat файлы будут CRLF, а .sh файлы будут LF через:

*.sh           text eol=lf

# *.bat
*.[bB][aA][tT] text eol=crlf

or

# *.sh are committed correctly as-is (LF)
*.sh           -text

# *.bat are committed correctly as-is (CRLF)
*.[bB][aA][tT] -text

Но да ... все не так просто. ха-ха.

[1 **]: это будет так для всех файлов, соответствующих text=auto attribute (т.е. не имеющих какой-либо другой специализации), поскольку я предполагаю, что ваше репо было правильно нормализовано при создании .gitattribute