Как настроить autocrlf в git для различных систем?

#git #git_config

Если я правильно понял, то в windows при autocrlf = true Git будет делать конвертацию
CRLF -> LF после коммита, а LF -> CRLF при чекауте.

В моем рабочем процессе возможны случаи, когда исходные файлы сбрасываются вручную,
минуя репозиторий, с рабочей директории репозитория первой машины Linux/Windows в рабочую
директорию второй Windows-машины.

При этом в этих исходных файлах строки содержат LF-окончание, а в рабочей директории
второй машины CRLF. Значит ли это, что придется вручную их конвертировать сторонним
софтом к CRLF виду? 

Как правильно настроить core.autocrlf на обеих рабочих машинах, чтобы избежать ошибок
при "ручном" переносе файлов?

Предполагаю, что в Windows - autocrlf = true, а в Linux - autocrlf = input (чтобы
предотвратить случай выше, только уже с CRLF).
    

Ответы

Ответ 1

Как правильно настроить core.autocrlf на обеих рабочих машинах, чтобы избежать ошибок
при "ручном" переносе файлов?


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

тогда при добавлении «ненормализованных» файлов (т.е., с разделителем строк crlf),
будет выдаваться предупреждение, что файл в репозитории будет преобразован, а при последующем
коммите файлы будут автоматически «нормализованы» (разделитель crlf будет заменён на lf).

а при выполнении команды checkout никаких преобразований делаться не будет — файлы
в рабочей копии будут иметь те же разделители, что и в репозитории1.

возможно, в операционных системах, где по умолчанию разделителем служит не lf, а
crlf (например, ms/windows), имеет смысл «пойти дальше», и присвоить атрибуту core.autocrlf
значение true — чтобы и при команде checkout производилось преобразование lf → crlf.
но это, вероятно, имеет смысл только в том случае, если используемая для просмотра/редактирования
этих файлов программа отображает содержимое файлов некорректно (т.е., не делает перенос
строки, встретив символ lf).



1 — посмотреть, как именно хранится файл в репозитории, можно, например, с помощью
команды git cat-file -p хэш. пример:

инициализируем репозиторий:

$ git init


добавляем в файл две строки и делаем коммит:

$ echo 1 > file; echo 2 >> file
$ git add file
$ git commit -m 1
[master (root-commit) 1373ad1] 1
 1 file changed, 2 insertions(+)
 create mode 100644 file


просматриваем содержимое коммита, указав его хэш (можно сокращённый):

$ git cat-file -p 1373ad1
tree d25d3b6082891168b6787cb20783bd332e5b8f74
...


просматриваем объект типа tree, добавленный этим коммитом:

$ git cat-file -p d25d3b6
100644 blob 1191247b6d9a206f6ba3d8ac79e26d041dd86941    file


просматриваем объект типа blob, содержащий тот самый файл:

$ git cat-file -p 1191247 | hexdump -C
00000000  31 0a 32 0a                                       |1.2.|
00000004


и видим, что сохранился он в репозитории с разделителем строк lf.


Ответ 2

Я протестировал все варианты и вот, что вышло:

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => CRLF ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  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, то так и останется.