Git заменяет LF на CRLF

Я мало что знаю о git'е на Windows, но...

По-моему, git преобразует формат возврата в формат, совпадающий с форматом на работающей платформе (Windows). CRLF - формат возврата по умолчанию в Windows, в то время как LF - формат возврата по умолчанию для большинства других ОС.

Скорее всего, формат возврата будет правильно настроен, когда код будет перемещён на другую систему. Я также считаю, что git достаточно умен, чтобы сохранить бинарные файлы в целости и сохранности, а не пытаться преобразовать LF в CRLF, скажем, в JPEG.

В общем, вам, наверное, не придётся слишком много беспокоиться об этом преобразовании. Однако, если вы архивируете свой проект как тарбол, коллеги-кодеры наверняка оценят наличие терминаторов LF-строк, а не CRLF. В зависимости от того, насколько вам не всё равно (и в зависимости от того, не используете ли вы Блокнот), вы, возможно, захотите установить в git'е использование LF-терминаторов, если можете :)

Приложение: CR - ASCII код 13, LF - ASCII код 10. Таким образом, CRLF - это два байта, в то время как LF - это один.

Git имеет три режима работы с окончаниями строк:

$ git config core.autocrlf
# that command will print "true" or "false" or "input"

Вы можете настроить этот режим, добавив дополнительный параметр true или false в вышеприведённую командную строку.

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

Побочный эффект этого удобного преобразования, и вот о чём предупреждение, которое вы видите, заключается в том, что если в текстовом файле, который вы создали, изначально были LF-концы вместо CRLF, то он будет храниться с LF, как обычно, но когда он будет извлечён позже, то будет иметь CRLF-концы. Для обычных текстовых файлов это обычно нормально. Предупреждение в данном случае - "к вашему сведению", но если git неправильно оценивает двоичный файл как текстовый, то это важное предупреждение, потому что в этом случае git будет повреждать ваш двоичный файл.

Если core.autocrlf установлен в false, то преобразование конца строки никогда не выполняется, поэтому текстовые файлы проверяются в as-is. Обычно это работает нормально, если все ваши разработчики работают либо под Linux, либо под Windows. Но, по моему опыту, я все еще склонен получать текстовые файлы со смешанными окончаниями строк, что в итоге приводит к проблемам.

Лично я предпочитаю оставить настройку включенной, как разработчик Windows.

Смотрите http://kernel.org/pub/software/scm/git/docs/git-config.html для получения обновленной информации, которая включает в себя значение "input".