Unix lf как преобразовать windows cr lf
Обновлено: 04.07.2024
Я разработчик Java и использую Ubuntu для разработки. Проект был создан в Windows с Eclipse и использует кодировку CP1252.
Для преобразования в UTF-8 я использовал программу перекодирования:
эта команда выдает эту ошибку:
Конвертировать окончания строк из CR/LF в один LF: отредактируйте файл с помощью vim, введите команду:set ff=unix и сохраните файл. Перекодировка теперь должна выполняться без ошибок.
Хорошо, но у меня есть много файлов для удаления символа CR/LF, я не могу открыть каждый, чтобы сделать это. Vi не предоставляет никаких опций командной строке для операций bash.
sed можно использовать для этого? Как?
Там должна быть программа под названием dos2unix это исправит конец строки для вас. Если его нет в вашей Linux-системе, он должен быть доступен через менеджер пакетов.
sed не может соответствовать \ n, потому что завершающий символ новой строки удаляется до того, как строка помещается в пространство шаблона, но может соответствовать \ r, поэтому вы можете преобразовать \ r \ n (dos) в \ n (unix), удалив \ r
Предупреждение: это изменит оригинальный файл
Тем не менее, вы не можете перейти с unix EOL на dos или старый mac (\ r). Больше чтений здесь:
На самом деле, Vim позволяет то, что вы ищете. Введите vim и введите следующие команды:
Первая из этих команд устанавливает список аргументов для каждого файла, соответствующего **/*.java , который является всеми файлами Java, рекурсивно. Вторая из этих команд, в свою очередь, выполняет следующие действия для каждого файла в списке аргументов:
- Устанавливает окончания строк в стиле Unix (вы уже знаете это)
- Записывает файл, если он был изменен
- Переходит к следующему файлу
Команда tr также может сделать это:
tr -d '\ 15 \ 32' unixfile.txt
и должен быть доступен для вас.
Вам нужно будет запустить tr из скрипта, так как он не может работать с именами файлов. Например, создайте файл myscript.sh:
Запуск myscript.sh Web будет обрабатывать все файлы Java в папке Web.
Я возьму небольшое исключение из ответа Джичао. Вы можете сделать все, о чем он только что говорил, довольно легко. Вместо того, чтобы искать \ n, просто ищите фид в конце строки.
Чтобы перейти с unix обратно на dos, просто найдите последний символ в строке и добавьте в него ленту новостей. (Я добавлю -r, чтобы сделать это проще с регулярными выражениями grep.)
Теоретически, файл можно изменить на стиль Mac, добавив в последний пример код, который также добавляет следующую строку ввода в первую строку, пока все строки не будут обработаны. Я не буду пытаться привести этот пример здесь.
Предупреждение: -i изменяет фактический файл. Если вы хотите сделать резервную копию, добавьте строку символов после -i. Это переместит существующий файл в файл с тем же именем, в котором ваши символы будут добавлены в конец.
Иногда бывает такая ситуация – получаешь от заказчика движок для его дальнейшего «допиливания». Пытаешься положить его в репозиторий Git – и получаешь кучу варнингов типа:
Это понятно - файлы в исходнике писались/правились до меня разными людьми и на разных операционных системах. Поэтому в файлах наблюдается полная мешанина в вопросе формата окончания строк.
Небольшая справка для тех, кто не в курсе. В разных операционных системах принят разный формат символов, обозначающий перевод строк:
- Windows - \r\n или CRLF (код 0D0A)
- Unix - \n или LF (код 0A)
- Mac - \r или CR (код 0D).
Такую разносортицу в своем проекте мне держать не хочется, поэтому я предпочитаю перед началом работ приводить все окончания строк к единому виду - \n, он же LF. Почему так? Большинство серверов работают под управлением систем на базе Unix, поэтому, на мой взгляд, логично использовать nix’овые окончания строк и для файлов движка сайта.
Теперь опишу свой способ приведения конца строк к единому виду. Описывать работу буду на примере графической оболочки Git – Git GUI. Так проще и нагляднее.
- Кладу все файлы движка в папку – например, Original.
- Удаляю всякие временные файлы и прочий мусор.
- В пустые папки, которые тем не менее необходимы для работы сайта, кладу файл readme.txt. Это надо по той причине, что Git отслеживает только файлы, а не папки. Поэтому если закоммитить в Git движок с пустыми папками, то потом при выгрузке движка этих пустых, но нужных папок мы не увидим.
- Открываю пункт меню «Редактировать» -> «Настройки» и указываю имя пользователя, email и кодировку файлов проекта.
- В файлах настроек Git – gitconfig - для параметра core прописываю:
- autocrlf = input
- safecrlf = warn
или выполнить команды:
- $ git config --global core.autocrlf input
- $ git config --global core.safecrlf warn
Первый параметр дает команду Git заменить все окончания строк с CRLF в LF при записи в репозиторий.
- В результате этой манипуляции у нас на диске C появилась папка Target, в которой лежат файлы из репозитория папки Original. Т.е. в папке Target все концы строк приведены к формату LF или CR.
- Заходим в папку Target, видим в ней папку .git – удаляем эту папку.
- Открываем редактор Notepad++, выбираем пункт меню «Вид» -> «Отображение символов» -> отмечаем «Отображать символ Конец строки». Теперь редактор будет нам показывать символы конца строк.
- Выбираем пункт меню «Поиск» -> «Искать в файлах». В настройках поиска выбираем:
- Режим поиска – Расширенный
- Папка – C:\Target
- Найти - \r
- В итоге мы найдем все файлы, которые имеют концы строк в формате Mac, т.е.\r или CR. Вряд ли их будет много, но иногда встречаются. Открываем каждый файл по очереди в том же редакторе Notepad++. Мы сможем визуально увидеть, что у файла концы строк в формате Mac:
- Преобразуем его в Unix формат. Выбираем «Правка» -> «Формат Конца Строк» -> «Преобразовать в UNIX-формат»
- Сохраняем файл и выполняем аналогичное преобразование для всех оставшихся файлов в формате Mac. В итоге в папке Target мы будем иметь движок, все файлы которого будут иметь конец строк Unix-формата LF.
Еще записи по теме
Такую петлю через git пришлось делать потому что CRLF концов много? Если я правильно понял, во всех файлах можно было сделать «Правка» -> «Формат Конца Строк» -> «Преобразовать в Win-формат»
Admin: да, можно в каждом файле отдельно формат концов строк поменять. Но т.к. файлов очень много, то пока не придумал ничего лучше такого вот "пакетного" изменения сразу во всех файлах.
Спасибо. Долго искал. Изощрённый метод однако
Как раз с данной ошибкой (LF will be replaced by CRLF ) столкнулся, но смотрю что в Нетбинсе "Правка"->"Замена", выбираем что регулярка и пишем с \r\n на \n и оно во всех файлах приведет к линуксовскому виду, ну типа того что вы добились гитом
Недавно я вернулся в Windows из Linux. У меня есть файлы с CRLF, некоторые с LF и некоторые из них смешанные. Есть ли утилита, которая поможет мне найти все мои файлы, связанные с Unix, и преобразовать их в соответствующие файлы с завершенным CRLF?
Утилита должна работать в Windows, а не в Linux. Я уже переехал. Я бы предпочел не устанавливать Cygwin , если я могу его избежать.
Вы можете конвертировать их с помощью утилиты unix2dos на вашей платформе Linux. Существуют версии unix2dos для Windows .
Если у вас установлен Perl, вы также можете использовать этот один вкладыш:
Вот простой и быстрый способ.
Перетащите текстовый файл в Chrome (я не знаю других браузеров), а затем вырезаем и вставляем обратно в исходный файл:)
Например: sfk addcr -dir . -file .txt -norec
изменяет LF-окончания в CR /LF для Windows, на всех .txt-файлах текущего каталога, но НЕ внутри подкаталогов (без рекурсии).
Но эта программа намного больше, чем просто.
В Cygwin вы можете конвертировать между файлами Unix и DOS AKA Windows с помощью двух встроенных утилит:
Преобразование в формат DOS CR /LF:
Преобразуйте обратно в формат Unix CR:
Файл остается на месте с тем же именем.
Итак, теоретически вы можете сделать это для преобразования всего дерева
Измените crlf на lf , если вы хотите пойти в другую сторону. ПРИМЕЧАНИЕ: вы еще не закончили, продолжайте читать
Введите git status , чтобы увидеть, какие файлы будут затронуты. Возможно, вам придется добавить строки, например
и т. д. до .gitattributes , чтобы избежать преобразования определенных файлов. Вы также можете указать определенные файлы как текст
Затем просто повторите эти 2 строки после редактирования .gitattributes
Затем снова используйте git status , чтобы узнать, какие файлы будут изменены. Когда вы уверены, что все файлы, которые вы хотите затронуть, перечислены в git status , а затем зафиксируйте
теперь проверьте все файлы снова
Теперь у них должно быть все, что у вас есть,
** ПРИМЕЧАНИЕ. Если вы уже использовали git, пропустите первые три команды git. Если вы не использовали git, теперь вы можете удалить файл .gitattributes и .git .
** Резервное копирование файлов: git rm --cached -r удаляет их все (хотя они теоретически в вашем git repo (папка .git ), так как они восстанавливаются с помощью последней команды git reset --hard . Просто, поскольку файлы удаляются, лучше всего их резервировать.
В моем дистрибутиве Linux есть две небольшие утилиты: fromdos и todos , которые я использую для этой задачи.
Используйте текстовый редактор, который понимает оба конца строки, например SciTE или Notepad ++ , если вам не нужно преобразовывать всю строку, заканчивающуюся во всех ваших файлах, но просто не хотите видеть весь файл сгруппирован в первую строку.
Существует много способов перевода символов eoln в файлы TEXT, и у каждого есть любимый.
Но я всегда переношу файлы с Linux на Windows в режиме BINARY, затем открываю файлы TEXT в Windows с помощью редактора, способного открывать оба типа, и при необходимости сохранять их в любой форме.
Я использовал редактор файлов Programmers для этого, но Notepad ++ тоже может это сделать. WordPad также полезен [по крайней мере, для просмотра файлов с завершенным LF].
Я думаю о простых текстовых файлах, которые могут возникнуть в Linux, и их нужно читать в стандартном (стандартном) мире Windows. Я не уверен, что вы имели в виду под «unix-touched files».
Чтобы предложить дополнительные параметры (хотя мне больше всего понравился запрос пользователя user45832 ):
Онлайн-преобразователи
Пакетный /DOS однострочный (удаляет пустые строки) :
Powershell:
Получил последние два отсюда
Преобразование окончаний строки Unix в конец строки Windows:
Преобразование окончаний строк Windows в конец строки Unix:
Старые версии awk не включают sub . В таких случаях используйте ту же команду, но замените awk на gawk или nawk .
В Википедии есть решение в cmd:
В PowerShell существуют различные способы сделать это, изменив то, что было сделано в на этом вопросе .
Это также можно сделать в VBScript и JScript , которые также являются инструментами, которые уже доступны в Windows без установки стороннего приложения.
Я использовал, чтобы открыть файл в 'edit' и сохранить, поскольку это было выполнено .
Я недавно вернулся в Windows из Linux. У меня есть некоторые файлы с CRLF, некоторые с LF, а некоторые смешанные. Есть ли утилита, которая поможет мне найти все мои файлы, затронутые Unix, и преобразовать их в правильные файлы с расширением CRLF?
Утилита должна работать на Windows, а не на Linux. Я уже переехал. Я бы предпочел не устанавливать Cygwin, если смогу избежать этого.
Решения в этих так называемых повторяющихся вопросах все работают на платформах Linux или выполняют обратное преобразование. У меня больше нет Linux. У меня есть окна. все они доступны для Windows через Cygwin, GnuWin32, UnxUtils или тому подобное. Я полагаю, что есть сценарии Powershell, которые также могут это сделать, хотя я не знаю достаточно об этом, чтобы предоставить какие-либо ссылки. @quack: В вопросе конкретно говорится, что пользователь ищет что-то, что будет выполнять работу в Windows, используя утилиту Windows.Вы можете конвертировать их с помощью unix2dos утилиты на вашей платформе Linux. Также доступны unix2dos версии для Windows .
Если у вас установлен Perl, вы также можете использовать этот вкладыш:
Я сделал что-то похожее на это, но я использовал Python. @ Matthew Scouten: итак . вы нашли утилиту Unix, которая работает на Windows! Поздравляю! да и нет. Я написал свою проклятую утилиту. Я мог бы сделать это с самого начала, но я надеялся сэкономить 30 минут. К сожалению, я не был доволен доступными утилитами. Ближайшие найденные мной поврежденные двоичные файлы в каталоге. Есть проблемы с преобразованием с dos2unix и unix2dos - если файл имеет смешанные CRLF и LF, могут быть некоторые случаи, которые не будут заменены.Вот простой и быстрый способ.
Перетащите текстовый файл в Chrome (я не знаю о других браузерах), а затем вырезайте и вставляйте обратно в исходный файл :)
все браузеры могут читать окончания строк Unix просто отлично, включая IE. Но даже тогда WordPad может сделать это, как и современный Блокнот . Здесь важно, как автоматически конвертировать несколько файловТот, который я нашел лучше всего для рекурсивного обхода папок, разрешения файловых фильтров и простого поиска "\ r \ n" и замены его просто "\ n", был Notepad ++ .
Notepad ++ - одна из лучших бесплатных программ с открытым исходным кодом для Windows. Это очень просто и мощно. Он отлично справился с поиском / заменой окончания строки. Подрядчик проверяет кучу файлов .c и .h в нашем репозитории с окончаниями строк Linux \ r \ n, но, поскольку большинство людей стандартизировали средства сборки Windows / Eclipse, файлы не будут собираться до тех пор, пока не будут преобразованы окончания строк ,
Я думаю, что вы изменили окончание там: Linux - это \ n, Windows - это \ r \ n Notepad ++ также имеет простое Edit -> EOL Conversion меню, если количество конвертируемых файлов невелико.Например: sfk addcr -dir . -file .txt -norec
изменяет окончания LF на CR / LF для Windows во всех файлах .txt текущего каталога, но НЕ в подкаталогах (без рекурсии).
Но эта программа делает гораздо больше, чем просто это.
Я не уточняю, -norec потому что я хочу, чтобы рекурсия произошла, но это не похоже на этоНа Cygwin вы можете конвертировать файлы Unix и DOS AKA Windows, используя две встроенные утилиты:
Преобразовать в формат DOS CR / LF:
Конвертировать обратно в формат Unix CR:
Файл остается на месте с тем же именем.
Это иногда называется dos2unix или unix2dos в случае, если вы не можете найти его как u2d или d2u. Также есть unix2macЯ собираюсь выбросить это решение там. Git сделает это. Смотрите этот пост об этом
Так что теоретически вы можете сделать это, чтобы преобразовать все дерево
Изменение crlf к , lf если вы хотите пойти в другую сторону. ПРИМЕЧАНИЕ: вы еще не закончили, продолжайте читать
Введите, git status чтобы увидеть, какие файлы будут затронуты. Возможно, вам придется добавить такие строки, как
и т.д., чтобы .gitattributes избежать конвертации определенных файлов. Вы также можете явно пометить определенные файлы как текст
Затем просто повторите эти 2 строки после того, как вы отредактировали .gitattributes
Затем используйте git status снова, чтобы увидеть, какие файлы будут изменены. Когда вы будете уверены , что все файлы , которые вы хотите пострадавших перечислены git status затем совершить
Теперь проверьте все файлы еще раз
Теперь они должны иметь желаемое окончание строки
** ПРИМЕЧАНИЕ. Если вы уже использовали git, пропустите первые 3 команды git. Если вы не использовали git, теперь вы можете удалить .gitattributes файл и .git папку.
** Создайте резервные копии ваших файлов: git rm --cached -r все они удаляются (хотя теоретически они находятся в вашем git-репо (папке .git), так как они восстанавливаются последней командой git reset --hard . Просто, поскольку файлы удаляются, вероятно, лучше всего их поддержать вверх.
Один из самых частых вопросов о Гите — почему так сложно работать с окончаниями строк. В этой статье мы попробуем ответить на этот вопрос и рассказать о множестве опций и настроек для контроля над окончаниями строк в Гите.
Гит имеет дело с двумя системами для работы с концами строк в репозиториях. Корень проблемы в том, что популярные операционные системы по-разному обозначают конец строки: Unix, Linux и Mac OS X используют LF , а Windows CRLF . В этой статье мы не будем брать во внимание, что в предыдущих версиях Mac OS X использовался CR .
Ничего из этого не было бы проблемой, если бы каждый из нас жил в своём маленьком, изолированном мире и никогда не обменивался кодом между разными операционными системами. Под обменом кодом, в данном случае, будем понимать всё — от работы над кросс-платформенным проектом до копирования кода из браузера. Всякий раз, когда вы скачиваете архив проекта с Гитхаба, копируете код из чьего-то блога или гиста или используете код из файла на облачном хранилище, вы работаете с текстом, а значит имеете дело с невидимыми символами окончаний строк.
Все эти действия с кодом потенциально могут привнести разные настройки окончаний строк в вашу кодовую базу. Это может привести к беспорядочным диффам и сделать работу с Гитом в целом неприятной.
Основное решение, которое принял Гит для этой проблемы — указать, что лучший способ хранить окончания строк в репозитории для текстовых файлов — использование LF . Это правило ни к чему вас не принуждает, но большинство разработчиков, использующих Гит и Гитхаб, приняли его как соглашение и мы тоже рекомендуем так настроить ваш конфиг.
Основы
Перед тем, как мы опишем настройки для управления окончаниями строк, нам надо узнать несколько вещей о core.eol и разобраться с тем, что значит записать что-либо в базу данных Гит.
Конец строки
core.eol — первый параметр, о котором нужно знать.
Почти всегда, кроме самых редких случаев, нам не стоит менять дефолтное значение этого параметра. Хотя сам по себе core.eol мало что делает, нам нужно знать его значение каждый раз, когда мы хотим, чтобы Гит изменил окончания строк. Так как этот параметр будет использоваться во всём, о чём пойдёт речь дальше, хорошо бы знать о его существовании и о том, что его значение, вероятно, менять не придётся.
- core.eol = native — значение по умолчанию. При записи файла в рабочую папку, Гит изменит окончания строк на соответствующие вашей платформе по умолчанию. Для Windows это будет CRLF , для Unix, Linux и Mac OS X — LF ;
- core.eol = crlf — если установлено такое значение, Гит всегда будет использовать для обозначения конца строки CRLF при записи файла в вашу рабочую директорию;
- core.eol = lf — это значение скажет Гиту всегда использовать LF для обозначения конца строки при записи файла в вашу рабочую папку.
Чтобы узнать, какое значение core.eol установлено в вашей системе, нужно запустить в консоли команду git config --global core.eol . Если команда ничего не вернёт, значит, в вашей системе используется значение по умолчанию, native .
Запись и вывод объектов из базы данных
Прежде чем двигаться дальше, мы поговорим о двух важных операциях: записи в объектную базу и выводе данных из неё в рабочую директорию. Возможно, вы уже знаете, что Гит хранит свою базу данных в папке .git . Он создаёт эту директорию и несколько файлов в ней, после запуска команды git init . Файлы в папке .git определяют все конфигурации Гита, в них хранится история проекта. Это обычные файлы и мы можем их читать и редактировать так же, как файлы самого проекта.
Каждый раз, когда мы делаем команду типа git commit , мы записываем объекты в эту базу данных. Запись в базу данных включает в себя:
- сохранение всего содержимого файла;
- добавление его в список со всеми файлами, которые отслеживает Гит;
- создание блоб-файла;
- вычисление SHA-ключа — хэш-кода, в котором хранится информация о содержимом файла.
Во время записи в базу данных **Гит может запустить фильтры и преобразовать окончания строк.
Есть ещё один случай, когда у Гита появляется возможность преобразовать окончания строк — это запись файлов из базы данных в нашу рабочую папку. Это то, что мы подразумеваем под выводом из базы данных. Такой процесс можно запустить множеством команд, но самая очевидная и простая для понимания — git checkout . Вывод из объектной базы данных также происходит после запуска команд, которые делают изменения в нашей рабочей папке, например, git clone или git reset .
Старая система
Теперь давайте поговорим о старой системе — оригинальном наборе функций в Гите, предназначенном для решения конкретной проблемы с окончаниями строк. Есть большая вероятность, что вы прямо сейчас пользуетесь старой системой и даже не подозреваете об этом.
Вот как это работает: у Гита есть настройка конфигураций core.autocrlf , которая специально создана для того, чтобы все окончания строк в текстовом файле преобразовывались в LF при записи в объектную базу данных репозитория. Вот список разных настроек для core.autocrlf и их значений:
- core.autocrlf = false — это значение по умолчанию, которое большинству людей следует сменить. Результатом использования этого значения станет то, что Гит не будет связываться с окончаниями строк в ваших файлах. Там могут быть разные окончаниями строк: LF , CRLF , CR или микс из всех них, но Гиту это будет безразлично. Такое значение может привести к тому, что диффы станут менее читаемыми и появятся сложности при слиянии веток. У большинства пользователей Unix/Linux установлено именно это значение, потому что у них нет проблем с CRLF и им не нужно, чтобы Гит делал дополнительную работу каждый раз при записи файлов в базу данных или в рабочую папку.
- core.autocrlf = true — значит, что Гит обработает все текстовые файлы и убедится, что все CRLF заменены на LF перед записью в базу данных. При обратном процессе он преобразует все LF в CRLF . Такая установка гарантирует, что ваш репозиторий можно будет использовать на других платформах, сохраняя CRLF в вашем рабочей папке. Поэтому параметр true для core.autocrlf рекомендован для Windows.
- core.autocrlf = input — значит, что Гит обработает все текстовые файлы и убедится, что все CRLF изменены на LF при записи файлов в базу данных. Однако обратной замены не произойдёт. При записи файлов в рабочую папку из базы данных, для обозначения конца строки останутся LF . Этот параметр обычно используется в Unix / Linux / OS X для предотвращения записи CRLF в репозиторий. Идея заключается в том, что если вы вставили код из браузера и случайно записали CRLF в один из ваших файлов, Гит удостоверится, что произойдёт замена на LF при записи в базу данных.
Чтобы увидеть, какое значение для core.autocrlf установлено в вашей системе, нужно запустить в командной строке git config --global core.autocrlf . Если команда ничего не вернёт, то вы используете значение по умолчанию, false .
Как же Гит определяет, что файл текстовый? Хороший вопрос. У Гита есть внутренний эвристический метод, который проверяет, двоичный ли файл. Если файл не двоичный, то Гит считает его текстовым. Но Гит иногда может ошибаться, и это будет причиной для знакомства со следующей настройкой.
Параметр core.safecrlf был создан на тот случай, если Гит ошибётся и изменит окончания строк там, где лучше было бы оставить их в покое.
- core.safecrlf = true — перед записью в базу данных при подготовке к замене CRLF на LF , Гит убедится, что сможет успешно прервать операцию. Он проверит, что можно откатить изменения (из LF в CRLF ), а если нет, то отменит операцию.
- core.safecrlf = warn — сделает то же, что и предыдущий параметр, но вместо того, чтобы прервать операцию, Гит просто предупредит вас о том, что может случиться что-то нехорошее.
Наконец, вы можете создать в корне своего репозитория файл .gitattributes и указать в нём настройки для конкретных файлов. Это позволит вам управлять такими настройками, как autocrlf для каждого типа файлов.
Например, для того, чтобы Гит заменил CRLF на LF во всех текстовых файлах, можно написать в .gitattributes такую строку:
Или можно сделать, чтобы Гит никогда не заменял CRLF на LF в текстовых файлах с помощью такой строки:
Чтобы Гит заменял CRLF на LF в текстовых файлах только при записи в базу данных, но возвращал LF при записи в рабочий каталог, нужно написать:
Хорошо, видите, какой беспорядок мы тут учинили? И он становится ещё больше, если мы начинаем работать над проектами, которые подталкивают нас к другим глобальным настройкам. Введём в дело новую систему, доступную начиная с версии Гит 1.7.2.
Новая система
Новая система определяет все настройки для окончаний строк в файле .gitattributes вашего репозитория, инкапсулируя их внутри и делая независимыми от глобальных настроек.
В новой системе за то, чтобы указать Гиту, в каких файлах надо заменить CRLF на LF , отвечаете вы, сообщая об этом с помощью атрибута text в файле .gitattributes . В этом случае будет полезен мануал для .gitattributes , а ниже вы найдёте несколько примеров использования атрибута text .
- *.txt text — устанавливает атрибут text для всех текстовых файлов. Это значит, что Гит будет запускать процесс замены CRLF на LF каждый раз при записи в БД и делать обратную замену при выводе из базы данных в рабочий репозиторий.
- *.txt -text — снимет со всех текстовых файлов этот фильтр. Это значит, что в указанных файлах не будет замены CRLF на LF .
- *.txt text=auto — установит для всех, подходящих под условие файлов, замену CRLF на LF , если Гит с помощью своего эвристического метода определит эти файлы как текстовые, а не бинарные.
Если файл не определён, Гит вернётся к старой системе и настройке core.autocrlf .
Именно так работает обратная совместимость, но я рекомендую, особенно тем, кто использует Windows для разработки, явно создавать файл gitattributes.
Ниже пример файла .gitattributes с общими настройками, который можно использовать для своего проекта. Пример взят отсюда.
Как вы могли заметить, с помощью следующей команды можно сказать Гиту обнаруживать все текстовые файлы и автоматически конвертировать в них CRLF в LF :
Читайте также: