Почему я должен использовать core.autocrlf = true в Git?

У меня есть репозиторий Git, к которому обращаются как из Windows, так и из OS X, и что я знаю, уже содержит некоторые файлы с концами строк CRLF. Насколько я могу судить, есть два способа справиться с этим:

  • Установите core.autocrlf в false всюду,

  • Следуйте инструкциям здесь (эхом на страницах справки GitHub), чтобы конвертировать репозиторий в список только LF line-endings, а затем установить core.autocrlf в true в Windows и input в OS X. Проблема с этим заключается в том, что если у меня есть какие-то двоичные файлы в репозитории, которые:

    • неправильно помечены как двоичные в gitattributes, а
    • содержат как CRLF, так и LF,

    они будут повреждены. Возможно, мой репозиторий содержит такие файлы.

Так почему бы мне просто не отключить преобразование окончания строки Git? В Интернете много неопределенных предупреждений о выключении core.autocrlf, вызывающих проблемы, но очень мало конкретных; единственное, что я нашел до сих пор, это то, что kdiff3 не может обрабатывать окончания CRLF (не проблема для меня), и что некоторые текстовые редакторы имеют проблемы с окончанием строки (также не проблема для меня).

Репозиторий является внутренним для моей компании, поэтому мне не нужно беспокоиться о том, чтобы поделиться им с людьми с разными настройками autocrlf или требованиями к завершению линии.

Есть ли какие-либо другие проблемы с оставлением окончаний строки, так как я не знаю?

ОТВЕТЫ

Ответ 1

Единственные конкретные причины для установки autocrlf в true:

  • избегайте git status показывающего все ваши файлы как modified из-за автоматического преобразования EOL, выполняемого при клонировании репозитория EOL GIT на основе Unix в Windows (например, см. выпуск 83)
  • и ваши инструменты кодирования так или иначе зависят от того, какой стиль EOL присутствует в вашем файле:
    • например, генератор кода, жестко запрограммированный для обнаружения нативного EOL
    • другие внешние пакеты (внешние для вашего репо) с регулярным выражением или набором кодов для обнаружения собственного EOL
    • Я считаю, что некоторые плагины Eclipse могут создавать файлы с CRLF независимо от платформы, что может быть проблемой.
    • Вы кодируете с помощью Notepad.exe(если вы не используете Windows 10 2018. 09+, где Notepad учитывает обнаруженный символ EOL).

Если вы не видите специфическую обработку, которая должна иметь дело с нативным EOL, вам лучше оставить autocrlf в false.

Обратите внимание, что этот конфиг будет локальным (поскольку конфиг не перемещается из репо в репо)

Если вам нужна одинаковая конфигурация для всех пользователей, клонирующих этот репозиторий, посмотрите " Какова лучшая стратегия обработки CRLF с помощью git? ", Используя атрибут text в файле .gitattributes.

Примечание: начиная с git 2.8 (март 2016 г.), маркеры слияния больше не будут вводить смешанный конец строки (LF) в файле CRLF.
Смотрите " Заставьте Git использовать CRLF на его" <<<<<<< HEAD "объединить строки "

Ответ 2

Я разработчик .NET и уже несколько лет использовал Git и Visual Studio. Моя сильная рекомендация - установить окончание строки в true. И сделайте это как можно раньше в течение всего срока службы вашего репозитория.

При этом я НЕНАВИЖУ, что Git меняет окончание строки. Исходный элемент управления должен сохранять и извлекать только то, что я делаю, оно НЕ должно его изменять. Когда-либо. Но это так.

Что произойдет, если у каждого разработчика не установлено значение true, ONE разработчик в конечном итоге установит значение true. Это начнет изменять окончание строк всех ваших файлов на LF в вашем репо. И когда пользователи установят false, проверьте их, Visual Studio предупредит вас и попросит вас их изменить. У вас будет 2 вещи, которые происходят очень быстро. Во-первых, вы получите все больше и больше этих предупреждений, чем больше ваша команда, тем больше вы получите. Вторая и, что еще хуже, заключается в том, что она покажет, что каждая строка каждого измененного файла была изменена (потому что окончание строк каждой строки будет изменено истинным парнем). В конце концов, вы больше не сможете отслеживать изменения в своем репо. Намного проще и чище заставить всех оставаться верными, чем пытаться держать всех в ложном свете. Как ужасно, так как нужно жить с тем, что ваш доверенный источник управления делает что-то, чего он не должен. Когда-нибудь.

Ответ 3

Обновление

Примечание. Как отмечено VonC, начиная с Git 2.8, маркеры слияния не будут выводить строки в стиле Unix в файл в стиле Windows.

Оригинал

Одна маленькая икота, которую я заметил с этой настройкой, заключается в том, что при конфликтах слияния строки Git добавляются, чтобы разметить различия, не имеют строк строк Windows, даже если остальная часть файла, и вы можете получить файл со смешанными окончаниями строки, например:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

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

Другая вещь * которую мы обнаружили, заключается в том, что при использовании git diff для просмотра изменений в файле с окончанием строки Windows строки, которые были добавлены, отображают их возврат каретки, таким образом

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

* Это действительно не значит, что термин "проблема".