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

Question

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

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

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

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

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

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

457

git line-endings

Источник

user328936 13 май '10 в 08:50

6 ответов

Решение

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

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

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

70

Источник

user3893353 10 июн '16 в 13:23

Обновление:

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

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

13

Источник

user328936 16 янв '12 в 16:50

Для меня.

Отредактируйте файл.gitattributes.

добавлять

*.dll binary

Тогда все идет хорошо.

0

Источник

user5637842 24 июл '20 в 06:32

Я работаю над GitHub и считаю эту статью полезной.

В нем описывается конфигурация git autocrlf и файл настроек .gitattributes.

0

Источник

user13050402 27 май '21 в 06:52

В нашем проекте мы заявили о необходимости установки autocrlf на входное значение. Вот почему вас это может заинтересовать:

Ваш проект работает в среде Linux/Unix, а разработчики пишут код в Windows. Во время отправки CRLF автоматически преобразуется в LF, поэтому вам просто нужно проверить репозиторий Git на сервере Unix, и все будет хорошо из коробки.
Иногда разработчики загружают конфигурацию с компьютеров Windows на серверы вручную с помощью WinSCP. Это приводит к окончанию строки CRLF на машинах Unix и неудачному запуску приложения. "входное" значение частично исключает количество таких случаев

Проблемы, с которыми мы столкнулись не так давно:

Если окончания строк установлены на CR (не CRLF) на машине разработчика, во время отправки они не будут преобразованы в LF и останутся CR в репозитории GIT. Тщательно проверяйте окончания строк

0

Источник

user537246 13 дек '21 в 11:57

Другие вопросы по тегам git line-endings

user6309 13 май '10 в 09:55 2010-05-13 09:55 · Accepted Answer · 2010-05-13 09:55

Единственные конкретные причины для установки 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 стратегия обработки с мерзавцем? ", с использованием text атрибут в .gitattributes файл

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