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

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

1. Набор core.autocrlfдля falseвезде,

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

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

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

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

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

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

Единственные конкретные причины , чтобы установить 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 ( git config --global core.autocrlf false).

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

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

Пример:

*.vcproj    text eol=crlf
*.sh        text eol=lf

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

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

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

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

Обновление 2 :

Xcode 9, кажется, имеет «особенность», в которой он будет игнорировать текущие окончания строки файла, и вместо этого просто использовать настройку окончания строки по умолчанию при вставке строк в файл, что приводит к файлам со смешанными окончаниями строк.

Я почти уверен, что этой ошибки не было в Xcode 7; не уверен насчет Xcode 8. Хорошей новостью является то, что, похоже, это исправлено в Xcode 10.

За то время, что она существовала, эта ошибка вызывала небольшое количество веселья в кодовой базе, на которую я ссылаюсь в этом вопросе (который используется по сей день autocrlf=false), и привела ко многим сообщениям коммита «EOL» и, в конечном итоге, к моему написанию git- pre-commitхука для проверки для / предотвращения введения смешанных концов строки.

Обновить :

Примечание: Как было отмечено 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

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