Какая лучшая стратегия обработки CRLF (возврат каретки, перевод строки) с Git?
Я попытался зафиксировать файлы со строками, заканчивающимися CRLF, но это не удалось.
Я провел целый рабочий день на своем компьютере с Windows, пробуя разные стратегии, и меня почти тянет перестать пытаться использовать Git и вместо этого попробовать Mercurial.
Пожалуйста, поделитесь только одним передовым опытом в каждом ответе.
Ответы 8
Не конвертируйте окончания строк. Работа VCS не состоит в том, чтобы интерпретировать данные - просто храните и изменяйте их. В любом случае любой современный текстовый редактор может читать оба типа окончания строк.
Я был бы доволен этой стратегией, но - я что-то делал не так? - git отказался бы от моих коммитов, если бы я не конвертировал файлы вручную с помощью dos2unix или если бы я не настраивал его с помощью autocrlf. Что-то вроде «патч содержит подозрительные строки», а иногда и «подозрительные пробелы в eol».
Дэниел: Я не использую Git, но, скорее всего, это вариант конфигурации в репозитории.
Не согласен. Встроенные переводы строк на всех платформах - это удобство.
Visual Studio - это PITA, когда дело касается чего-либо, кроме CRLF.
Git имеет возможность не преобразовывать окончания строк, это autocrlf = false, и если вы не занимаетесь кросс-платформенной разработкой, например, Mono, лучше оставить false при работе под Windows и установить значение true, если вы будете разрабатывать с открытым исходным кодом. для Mono.
Без объяснения, какие настройки использовать, чтобы избежать преобразования окончаний строк, этот ответ не очень полезен.
Проблема с окончанием строки заключается в вычислении правильных различий. Так что ответ неверен и вводит в заблуждение.
Если вы работаете в Windows, у вас действительно нет особого выбора. Вам нужно иметь файлы в режиме CRLF в Windows и LF только на Unix-ish платформах.
Подавляющее большинство людей, использующих sftp для текстовых файлов unix> win, используют WinSCP ... это отличная программа с раздражающей оговоркой, что она принудительно преобразуется в окончания DOS и не может быть изменена. Если вы используете WinSCP, то это определенно вопрос, на который нужно ответить, а не взорвать его словами «не делайте этого».
@escouten - в Windows у вас нет имеют, чтобы иметь файлы в crlf, просто редакторы Windows могут быть настроены по умолчанию для сохранения в этом формате. Измените параметры вашего редактора. Открытие файлов 'lf' eol не является проблемой в Windows. (Если вы используете Блокнот в качестве основного редактора, тогда остановитесь.) Во многих случаях вам все еще нужен «оригинальный» eol, а не преобразованный eol; например, вы не можете запускать сценарии bash под cygwin, если они преобразованы в crlf; Модульные тесты могут иметь файлы ввода / вывода, которые "повреждены" в результате этого преобразования и т. д.
@monsto - конечно можно sftp без конвертации; включить двоичное преобразование или использовать scp. по умолчанию sftp выполняет преобразование текста; по умолчанию scp выполняет двоичную передачу; и sftp (в том числе интерактивный) имеет возможность отключить преобразование.
Что ж, я думаю, что Джон Милликин пытается объяснить, что в случае редактирования файлов linux в редакторе Windows вы можете изменить поведение редактора, указав что-то вроде SublimeText в своих настройках: '"default_line_ending": "unix"'
+1, не изменяйте EOL, когда ваша команда делится файлами .bat и .sh в одном репо.
Почему мы не можем решить все проблемы с окончанием строки, просто определив LF = CRLF во всех наших инструментах? Это уже работает так во многих инструментах, особенно в инструментах Windows. Не стесняйтесь, поддержите обоих, если ваш проект обрабатывает символы новой строки, и относитесь к ним как к равным!
Вы просто предположили, что они будут редактировать файлы. Тем не менее, я бы хотел увидеть, как вы попытаетесь скомпилировать файлы с окончанием строки Windows в Linux.
Нет, нет, если у вас есть коммиттеры, работающие на разных платформах - у меня были репозитории, которые были настолько загружены из-за различий в EOL, что мне пришлось их уничтожить и перестроить из рабочих пространств (и не говорите «не делайте этого» ", потому что часто нет законной причины заставлять всех стандартизироваться). Самый простой подход - выбрать один стандарт EOL (я бы предложил \n, чтобы вы могли сэкономить эти лишние байты :-) и убедиться, что все клиенты правильно настроены для каждой ОС. Если ваши .gitattributes определены правильно, Git всегда будет делать все правильно, совершенно прозрачно для разработчика.
Не согласен, если ваша главная машина - это Windows, у вас действительно нет особого выбора.
@RomanStarkov Потому что для создания смешанного файла LF + CRLF требуется всего один инструмент, что приносит массу дополнительных проблем; и это до того, как перейти к кодировке текста. Основная проблема остается той же, что и в течение десятилетий - не существует такого понятия, как «текстовый файл», и мы должны перестать притворяться, что есть. Конечно, этого не произойдет в ближайшее время - особенно с учетом того, что так много форматов файлов возвращаются к тексту для взаимодействия (по крайней мере, XML не делает вид, будто проблемы не существует; другие не такие счастливые маленькие деревца: /).
Плохой совет. Посмотрите, что может случиться с неродными окончаниями строк stackoverflow.com/a/53611093/3700414
Попробуйте установить для параметра конфигурации core.autocrlf значение true. Также обратите внимание на вариант core.safecrlf.
На самом деле похоже, что core.safecrlf уже может быть установлен в вашем репозитории, потому что (выделено мной):
If this is not the case for the current setting of core.autocrlf, git will reject the file.
В этом случае вы можете проверить, настроен ли ваш текстовый редактор для последовательного использования окончаний строк. Вы, вероятно, столкнетесь с проблемами, если текстовый файл будет содержать окончание строк LF и CRLF.
Наконец, я считаю, что рекомендация просто «использовать то, что вам дано» и использовать линии с завершением LF в Windows, вызовет больше проблем, чем решит. У Git есть указанные выше параметры, чтобы попытаться разумно обработать окончания строк, поэтому имеет смысл их использовать.
Не лучше ли использовать настройки всего репозитория через файл .gitattributes? Было просто интересно: неудобно заставлять каждого пользователя заботиться о своих настройках окончания строки на своей машине ... Или есть другие недостатки?
Вам почти всегда нужен autocrlf=input, если вы действительно не знаете, что делаете.
Дополнительный контекст ниже:
It should be either
core.autocrlf=trueif you like DOS ending orcore.autocrlf=inputif you prefer unix-newlines. In both cases, your Git repository will have only LF, which is the Right Thing. The only argument forcore.autocrlf=falsewas that automatic heuristic may incorrectly detect some binary as text and then your tile will be corrupted. So,core.safecrlfoption was introduced to warn a user if a irreversable change happens. In fact, there are two possibilities of irreversable changes -- mixed line-ending in text file, in this normalization is desirable, so this warning can be ignored, or (very unlikely) that Git incorrectly detected your binary file as text. Then you need to use attributes to tell Git that this file is binary.
Приведенный выше абзац изначально был взят из ветки на gmane.org, но с тех пор его нет.
Почему это «Правильное дело»?
core.autocrlf = true - ужасная идея. У меня не было проблем с этой опцией, к тому же вы должны не забывать устанавливать ее всякий раз, когда клонируете репозиторий.
Я подозреваю, что это неверный ответ. Совет несовместим с тем, что я читал в другом месте.
НЕ используйте autocrlf = true, если вы не знаете, что делаете. Если вы разрабатываете в DOS / Win, тогда autocrlf = false сохранит окончания одинаковыми для удаленного и локального репо и является лучшим вариантом почти в любой ситуации.
@Chris - Что, если у ваших разработчиков есть окна и многоплатформенные проекты, в которых некоторые многоплатформенные разработчики работают на OSX или Linux? Разве тогда не должен быть лучшим вариантом autocrlf = true?
Это был бы единственный сценарий, в котором это имело бы смысл, но это не так распространенный сценарий, поэтому он не имеет смысла по умолчанию, а только для каждого репо.
autocrlf = true подходит, если вы можете правильно инициализировать репо (или в какой-то момент удалить CRLF / CR). Многие редакторы (особенно в Windows?) Создают CRLF и имеют проблемы со смешанным переводом строки. Например: минимальное изменение может привести к преобразованию каждой строки. git-diff также имеет проблемы при смешивании CR с CRLF.
Ссылка на kerneltrap.org не работает, пост можно найти здесь thread.gmane.org/gmane.comp.version-control.git/79726/…
@BrettRyan - autocrlf = true никогда не бывает самым безопасным вариантом.
Я не согласен, я работаю над многими проектами, где разработчики Windows могут испортить окончания строк. Но сейчас я использую .gitattributes во всех проектах.
core.autocrlf=input is the canonical answer. For most use cases, core.autocrlf=true and core.autocrlf=false are overly zealous (...in opposite but equally terrible ways, of course) and hence intrinsically destructive. "Git for Windows" should В самом деле have shipped with "Checkout as-is, commit Unix-style line endings" (i.e., core.autocrlf=input) as its default newline strategy. It didn't. So here we here – в гребаном 2015 году – still endlessly debating this.
Спасибо @CecilCurry - я уточнил текст на основе ваших отзывов.
@CecilCurry На днях я узнал, почему бы и нет. Есть две вещи Windows, которые не поддерживают символы новой строки в стиле Unix; Блокнот (не проблема, не используйте его) и текстовые поля Windows Forms. Visual Studio использует их в разных местах, в том числе ... для редактирования сценариев до и после сборки. Поэтому, если вы используете символы новой строки в стиле Unix, вы потеряете все символы новой строки сценария сборки в Visual Studio. Облом.
Ссылка вроде не работает.
Связанный: Ты просто еще один перевод строки возврата каретки в стене
Как упомянул @BrettRyan: не было бы лучше использовать настройки всего репозитория через файл .gitattributes? Было просто интересно: неудобно заставлять каждого пользователя заботиться о своих настройках окончания строки на своей машине ... Или есть другие недостатки?
autocrlf не работает; не используйте его (оставьте false) и используйте gitattributes и safecrlf = true Вот обсуждение основных разработчиков git по этому поводу: git.661346.n2.nabble.com/…
Использование core.autocrlf=false остановило пометку всех файлов как обновленных, как только я проверил их в своем проекте Visual Studio 2010. Два других члена команды разработчиков также используют системы Windows, поэтому смешанная среда не использовалась, но настройки по умолчанию, которые поставлялись с репозиторием, всегда помечали все файлы как обновленные сразу после клонирования.
Думаю, суть в том, чтобы выяснить, какие настройки CRLF подходят для вашей среды. Тем более, что во многих других репозиториях на наших ящиках Linux установка autocrlf = true дает лучшие результаты.
Спустя 20 с лишним лет мы все еще сталкиваемся с несоответствием окончания строк между ОС ... печально.
@ orange80, несоответствие прискорбно, но нет причин называть это ошибкой Windows. Возможно, только LF имеет смысл с минималистской точки зрения; но CRLF имеет больше смысла в зависимости от того, что означают CR и LF. «Возврат каретки» означает возврат в начало строки; «перевод строки» означает переход прямо к следующей строке, а не к ее началу. С семантической точки зрения Windows более правильна, имея и то, и другое: вернуться в начало (CR) и затем на одну строку вниз (LF).
@Kyralessa "правильнее" по-прежнему притворяться, что компьютер - это пишущая машинка, а это не так, кстати. Поддерживать аналогию с пишущей машинкой не имеет никакого смысла, учитывая, что это не то, с чем когда-либо будут иметь дело конечные пользователи, и что два символа вместо одного бессмысленно.
Поздно до этой вечеринки на несколько лет, но вы проигнорировали тот факт, что CR и LF являются инструментами позиционирования курсора. «CR» также может быть «возвратом курсора» на данном этапе истории. Если бы я хотел, чтобы курсор вернулся в начало строки, я бы сказал приложению сделать это. В противном случае он должен оставаться там, где я его положил.
Кроме того, если CRLF является «более правильным», потому что новая строка текстового файла на самом деле является одновременно «перемещением на одну строку вниз» и «перемещением в начало строки», из этого следует, что просто CR заставит текстовый редактор перезаписать строку с следующая строка. Я не знаю редакторов, которые действительно поддерживают это, а это означает, что необходимость выражать и CRLF, и CR как разные вещи на самом деле не существует.
@avl_sweden Это было очень распространенным поведением до DOS, и, поскольку Microsoft считает, что совместимость важна, с тех пор так и остается. Это также было стандартным способом в США (как и в случае с ASA) - ISO допускал использование как CR + LF, так и LF (опять же, DOS соответствовала стандартам); в обоих случаях с шестидесятых годов. Multics (предшественник Unix) поддерживал CR для жирного шрифта / strike. Многие современные приложения (в том числе функции .NET «разбиение по строкам») ищут любой из трех (одиночный CR, одинокий LF, CRLF) и рассматривают каждое из них как конечную строку. Тем не менее, многие приложения все еще сбивают с толку смешанные окончания строк в файле.
@avl_sweden Unicode имеет спецификаторы новой строки восемь, которые должны поддерживать все совместимые приложения. Но опять же, Unicode больше не претендует на существование чего-то вроде «обычного текстового файла» - он точно определяет, как каждый символ кодируется универсально в каждой системе. К сожалению, поддержки Unicode по-прежнему не хватает, и, похоже, она все еще довольно непопулярна, особенно в мире Unix. Программисты обычно даже не рассматривают потенциальные проблемы, пока не укусят их - я даже видел библиотеки HTTP, которые используют LF в качестве разделителя строк, хотя текстовые интернет-протоколы должны использовать CRLF ...
Спустя почти четыре года после того, как я задал этот вопрос, я наконец нашел ответ, который меня полностью удовлетворяет!
См. Подробности в руководстве github: помощь по Работа с окончаниями строк.
Git allows you to set the line ending properties for a repo directly using the text attribute in the
.gitattributesfile. This file is committed into the repo and overrides thecore.autocrlfsetting, allowing you to ensure consistent behaviour for all users regardless of their git settings.
И поэтому
The advantage of this is that your end of line configuration now travels with your repository and you don't need to worry about whether or not collaborators have the proper global settings.
Вот пример файла .gitattributes
# Auto detect text files and perform LF normalization
* text=auto
*.cs text diff=csharp
*.java text diff=java
*.html text diff=html
*.css text
*.js text
*.sql text
*.csproj text merge=union
*.sln text merge=union eol=crlf
*.docx diff=astextplain
*.DOCX diff=astextplain
# absolute paths are ok, as are globs
/**/postinst* text eol=lf
# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf
Есть удобный сборник готовых к использованию файлов .gitattributes для самых популярных языков программирования. Это полезно для начала.
После того, как вы создали или настроили свой .gitattributes, вы должны выполнить раз и навсегда повторная нормализация окончаний строк.
Обратите внимание, что приложение GitHub Desktop может предложить и создать файл .gitattributes после того, как вы откроете репозиторий Git вашего проекта в приложении. Чтобы попробовать это, щелкните значок шестеренки (в правом верхнем углу)> Настройки репозитория ...> Концы строк и атрибуты. Вам будет предложено добавить рекомендованный .gitattributes, и если вы согласны, приложение также выполнит нормализацию всех файлов в вашем репозитории.
Наконец, статья Не забывайте о конце своей строки предоставляет больше информации и объясняет, как Git развивался по текущим вопросам. Считаю это обязательное чтение.
У вас, вероятно, есть пользователи в вашей команде, которые используют EGit или JGit (такие инструменты, как Eclipse и TeamCity, используют их) для фиксации своих изменений. Тогда вам не повезло, как объяснил @gatinueta в комментариях к этому ответу:
This setting will not satisfy you completely if you have people working with Egit or JGit in your team, since those tools will just ignore .gitattributes and happily check in CRLF files https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
Один из приемов может заключаться в том, чтобы заставить их фиксировать свои изменения в другом клиенте, скажем, SourceTree. Тогда наша команда во многих случаях предпочитала этот инструмент Eclipse EGit.
Кто сказал, что программное обеспечение - это просто? : - /
Хотите поделиться Windows .gitattributes?
Как узнать, что .gitattributes предлагает GitHub для Windows для вашего проекта? Я установил GitHub для Windows, запустил версию с графическим интерфейсом и не смог найти ни одной опции, связанной с предложениями .gitattributes.
@JLDiaz, запустите GitHub для Windows и в списке репозиториев откройте нужный. Как только (и только один раз) у вас откроется репозиторий, щелкните меню инструменты, выберите настройки, и вы увидите справа, что я имел в виду.
@BrechtMachiels Если вы используете * text=auto !eol, вам все равно нужно установить autocrlf в конфигурации git?
@BrechtMachiels .gitattributes берет на себя конфигурацию autocrlf для репо, содержащего .gitattributes. Таким образом, кто-то может захотеть настроить autocrlf на общих основаниях для репозиториев, которые они используют, без .gitattributes. Но, возможно, я пропустил вашу часть !eol; Я не помню, что он делает.
Этот параметр не удовлетворит вас полностью, если в вашей команде есть люди, работающие с Egit, поскольку egit просто игнорирует .gitattributes и с радостью проверяет файлы CRLF bugs.eclipse.org/bugs/show_bug.cgi?id=342372
Для Windows я обычно склоняюсь к установке глобального core.autocrlf = false - я предпочитаю LF везде, но некоторые инструменты Windows, такие как Visual Studio, настаивают на окончании CRLF в определенных файлах (и даже смешивают их в некоторых ..); не изменять окончание строк - самый безопасный вариант. Если вы знаете, что делаете, я бы, вероятно, использовал core.autocrlf = input и сделал исключения для проектов в Windows, которые, как вы знаете, чувствительны к окончанию строк. Как отмечают другие, каждый приличный текстовый редактор теперь поддерживает окончания LF. Я действительно думаю, что core.autocrlf = true может доставить больше проблем, чем предотвратить.
Я думаю, что * text=auto применяется только к файлам в корневом каталоге [или, скорее, местонахождении каталога файлов .gitattributes], верно?
@gatinueta Чтобы быть более конкретным, это проблема JGit. Это означает, что TeamCity, который также использует JGit, прямо игнорирует .gitattributes.
Сборник готовых к использованию файлов .gitattributes для самых популярных языков программирования можно найти на github.com/Danimoth/gitattributes
Ссылка на «Не забывайте о конце своей линии» не работает. Это та же статья? Adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line
Visual Studio с git в Team Explorer (не Team City), похоже, поддерживает .gitattributes в соответствии с этим: blogs.msdn.com/b/visualstudioalm/archive/2013/02/26/…
Также рекомендую использовать *.sh text eol=lf
@DanielJomphe Что делать, если члены команды используют разные платформы? Как общий файл .gitattributes работает у кого-то в Windows, а у другого в Linux?
@DanielJomphe: Я бы добавил еще кое-что: установите core.safecrlf = true. Предотвращает горе, протестуя сразу при фиксации, а не позже
Разве это не плохой, чтобы «путешествовать с вашим репозиторием», поскольку каждый пользователь может работать с другой ОС?
Две альтернативные стать последовательным стратегии касательно окончания строк в смешанных средах (Microsoft + Linux + Mac):
А. Глобальный по настройке всех репозиториев
1) Преобразовать все в одном формате
find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'
2) Установите core.autocrlf на input в Linux / UNIX или true в MS Windows (репозиторий или глобальный)
git config --global core.autocrlf input
3) [Необязательно] установите core.safecrlf на true (чтобы остановить) или warn (чтобы петь :), чтобы добавить дополнительную защиту при сравнении, если обратное преобразование новой строки приведет к тому же файлу.
git config --global core.safecrlf true
Б. Или на настройку репозитория
1) Преобразовать все в одном формате
find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'
2) добавьте файл .gitattributes в свой репозиторий
echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'
Не беспокойтесь о своих двоичных файлах - Git должен уметь обращаться с ними.
Подробнее о переменных safecrlf / autocrlf
dos2unix - это инструмент командной строки, который, в зависимости от системы, может потребоваться установить дополнительно.
Они не исключительны, вы можете использовать оба подхода одновременно. Также будьте очень осторожны при использовании dos2unix - существует риск развращает .git/index, и нам не нужно применять его к каждому файлу. Лучше использовать что-то вроде find ./ -name "*.html" и указать, к каким файлам вы хотите его применить.
ПРЕДУПРЕЖДЕНИЕ: перед запуском строк find имейте в виду: dos2unix, который поставляется с Git для Windows, имеет своеобразное (идиотское и опасное IMO) поведение без аргументов: вместо перехода на UNIX он переключает формат новой строки (DOS <- > UNIX)
И еще одно предупреждение: DOS2UNIX не делает вашу папку .git. Просто говорю.
Это просто решение обходной путь:
В обычных случаях используйте решения, поставляемые с git. В большинстве случаев они отлично работают. Принудительно установите LF, если вы разделяете разработку в системах на базе Windows и Unix, установив .gitattributes.
В моем случае было более 10 программистов, разрабатывающих проект в Windows. Этот проект зарегистрирован с помощью CRLF и не было возможности форсировать LF.
Некоторые настройки были записаны внутри моей машины без какого-либо влияния на формат LF; таким образом, некоторые файлы глобально менялись на LF при каждом небольшом изменении файла.
Мое решение:
Windows-машины: Пусть все как есть. Ни о чем не заботятся, так как вы - разработчик Windows "одинокий волк" по умолчанию, и вам приходится поступать так: "Нет другой системы в большом мире, не так ли?"
Unix-машины
Добавьте следующие строки в раздел конфигурации
[alias]. Эта команда выводит список всех измененных (т.е. измененных / новых) файлов:lc = "!f() { git status --porcelain \ | egrep -r \"^(\?| ).\*\(.[a-zA-Z])*\" \ | cut -c 4- ; }; f "Преобразуйте все эти файлы измененный в формат dos:
unix2dos $(git lc)Необязательно ...
Создайте git крюк для этого действия, чтобы автоматизировать этот процесс
Используйте params, включите их и измените функцию
grep, чтобы она соответствовала только определенным именам файлов, например:... | egrep -r "^(\?| ).*\.(txt|conf)" | ...Не стесняйтесь сделать его еще удобнее, используя дополнительный ярлык:
c2dos = "!f() { unix2dos $(git lc) ; }; f "... и запустить преобразованный материал, набрав
git c2dos
Это два варианта для пользователей Окна и Visual Studio, которые совместно используют код с пользователями Mac или Linux. Для расширенного объяснения прочтите gitattributes руководство.
* текст = авто
В файле .gitattributes вашего репо добавьте:
* text=auto
Это нормализует все файлы с окончанием строки LF в репо.
И в зависимости от вашей операционной системы (параметр core.eol) файлы в рабочем дереве будут нормализованы до LF для систем на базе Unix или CRLF для систем Windows.
Это конфигурация, которую используют репозитории Microsoft .NET.
Пример:
Hello\r\nWorld
Будут нормализованы в репо всегда как:
Hello\nWorld
При оформлении заказа рабочее дерево в Windows будет преобразовано в:
Hello\r\nWorld
При оформлении заказа рабочее дерево на Mac останется следующим:
Hello\nWorld
Note: If your repo already contains files not normalized,
git statuswill show these files as completely modified the next time you make any change on them, and it could be a pain for other users to merge their changes later. See refreshing a repository after changing line endings for more information.
core.autocrlf = правда
Если text не указан в файле .gitattributes, Git использует переменную конфигурации core.autocrlf, чтобы определить, следует ли преобразовать файл.
Для пользователей Windows git config --global core.autocrlf true - отличный вариант, потому что:
- Файлы нормализуются по окончанию строки
LFтолько при добавлении в репо. Если в репо есть файлы, не нормализованные, этот параметр их не коснется. - Все текстовые файлы преобразуются в окончание строки
CRLFв рабочем каталоге.
Проблема с этим подходом в том, что:
- Если вы являетесь пользователем Windows с
autocrlf = input, вы увидите кучу файлов с окончанием строкиLF. Не представляет опасности для остальной части команды, потому что ваши коммиты по-прежнему будут нормализованы с окончанием строкиLF. - Если вы являетесь пользователем Windows с
core.autocrlf = false, вы увидите кучу файлов с окончанием строкиLFи можете добавить файлы с окончанием строкиCRLFв репозиторий. - Большинство пользователей Mac используют
autocrlf = inputи могут получать файлы с окончанием файлаCRLF, вероятно, от пользователей Windows сcore.autocrlf = false.
Ваша команда для пользователей Windows говорит git config --global core.autocrl true. Вы про git config --global core.autocrlf true.
Прикомандированный. Если у вас есть проблемы с непоследовательными окончаниями строк, лучшим решением будет кричать на тех, кто использует неправильные настройки редактора, пока они не исправят это.