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

Question

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

1. Установите core.autocrlf на false везде,

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

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

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

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

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

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

Answer 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 "</a>"

Answer 2

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

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

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

Answer 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

_{* Это на самом деле не заслуживает термина «выпуск».}