InterMaster.com.ru

О бизнесе в интернете, отдыхе в реале и просто о жизни…

Как я меняю в проектах концы строк с CRLF на LF

Иногда бывает такая ситуация – получаешь от заказчика движок для его дальнейшего «допиливания». Пытаешься положить его в репозиторий Git – и получаешь кучу варнингов типа:

Это понятно — файлы в исходнике писались/правились до меня разными людьми и на разных операционных системах. Поэтому в файлах наблюдается полная мешанина в вопросе формата окончания строк.

Небольшая справка для тех, кто не в курсе. В разных операционных системах принят разный формат символов, обозначающий перевод строк:

• Windows — \r\n или CRLF (код 0D0A)
• Unix — \n или LF (код 0A)
• Mac — \r или CR (код 0D).

Такую разносортицу в своем проекте мне держать не хочется, поэтому я предпочитаю перед началом работ приводить все окончания строк к единому виду — \n, он же LF. Почему так? Большинство серверов работают под управлением систем на базе Unix, поэтому, на мой взгляд, логично использовать nix’овые окончания строк и для файлов движка сайта.

Теперь опишу свой способ приведения конца строк к единому виду. Описывать работу буду на примере графической оболочки Git – Git GUI. Так проще и нагляднее.

1. Кладу все файлы движка в папку – например, Original.
2. Удаляю всякие временные файлы и прочий мусор.
3. В пустые папки, которые тем не менее необходимы для работы сайта, кладу файл readme.txt. Это надо по той причине, что Git отслеживает только файлы, а не папки. Поэтому если закоммитить в Git движок с пустыми папками, то потом при выгрузке движка этих пустых, но нужных папок мы не увидим.
4. Открываю пункт меню «Редактировать» -> «Настройки» и указываю имя пользователя, email и кодировку файлов проекта.
5. В файлах настроек Git – gitconfig — для параметра core прописываю:
   • autocrlf = input
   • safecrlf = warn

или выполнить команды:

• $ git config —global core.autocrlf input
• $ git config —global core.safecrlf warn

Первый параметр дает команду Git заменить все окончания строк с CRLF в LF при записи в репозиторий.

Второй – выдает предупреждения о конвертации специфических бинарников, если вдруг такие окажутся в движке.

Теперь записываю все файлы движка в репозиторий. В итоге в репозитории все файлы будут иметь концы строк LF или CR (т.к. Git сконвертировал только CRLF в LF, преобразование CR->LF от не выполняет).

Запускаю Git GUI, выбираю «Склонировать существующий репозиторий».

В строке «Исходное положение» указываю папку Original.

В строке «Каталог назначения» указываю полный пусть к папке, в которую я хочу скопировать репозиторий из папки Original. В данном случае я указал папку Target. Важно: папки с таким именем на диске быть не должно. Git GUI создаст ее сам.

Выбираю «Полная копия».

Жму «Склонировать».

1. В результате этой манипуляции у нас на диске C появилась папка Target, в которой лежат файлы из репозитория папки Original. Т.е. в папке Target все концы строк приведены к формату LF или CR.
2. Заходим в папку Target, видим в ней папку .git – удаляем эту папку.

1. Открываем редактор Notepad++, выбираем пункт меню «Вид» -> «Отображение символов» -> отмечаем «Отображать символ Конец строки». Теперь редактор будет нам показывать символы конца строк.

1. Выбираем пункт меню «Поиск» -> «Искать в файлах». В настройках поиска выбираем:
   • Режим поиска – Расширенный
   • Папка – C:\Target
   • Найти — \r

1. В итоге мы найдем все файлы, которые имеют концы строк в формате Mac, т.е.\r или CR. Вряд ли их будет много, но иногда встречаются. Открываем каждый файл по очереди в том же редакторе Notepad++. Мы сможем визуально увидеть, что у файла концы строк в формате Mac:

1. Преобразуем его в Unix формат. Выбираем «Правка» -> «Формат Конца Строк» -> «Преобразовать в UNIX-формат»

1. В итоге файл преобразуется в UNIX-формат.

1. Сохраняем файл и выполняем аналогичное преобразование для всех оставшихся файлов в формате Mac. В итоге в папке Target мы будем иметь движок, все файлы которого будут иметь конец строк Unix-формата LF.

Теперь движок можно класть в репозиторий Git. И не забудьте в редакторе, которым выпотом будете править файлы, выставить по умолчанию концовку строк LF, чтобы опять не возникла мешанина.

Еще записи по теме

Такую петлю через git пришлось делать потому что CRLF концов много? Если я правильно понял, во всех файлах можно было сделать «Правка» -> «Формат Конца Строк» -> «Преобразовать в Win-формат»

Admin: да, можно в каждом файле отдельно формат концов строк поменять. Но т.к. файлов очень много, то пока не придумал ничего лучше такого вот «пакетного» изменения сразу во всех файлах.

Спасибо. Долго искал. Изощрённый метод однако

Как раз с данной ошибкой (LF will be replaced by CRLF ) столкнулся, но смотрю что в Нетбинсе «Правка»->»Замена», выбираем что регулярка и пишем с \r\n на \n и оно во всех файлах приведет к линуксовскому виду, ну типа того что вы добились гитом

Все тоже самое что и в статье, только проще, в Notepad++

CTRL-F >> ‘Найти в файлах’

1. Выбираем ‘Режим поиска’ >> ‘Расширенный’

2. В поле ‘Папка’ выбираем папку с проектом

3. В поле ‘Найти’ пишем ‘\r\n’

4. В поле ‘Заменить на’ пишем ‘\n’

5. Жмем ‘Заменить в файлах’

6. После замены возвращаемся к шагу #3 и пишем ‘\r’, жмем заменить

LF will be replaced by CRLF in git — What is that and is it important? [duplicate]

When I create a new rails application I’m seeing a warning in git about LF replacement. I do git init git add .

and then boom! I see this pop up for almost all files. I usually just keep going and build my application and it disappears after many changes to files.

Example:

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in Gemfile.

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in Gemfile.lock.

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in README.

What’s the difference between LF and CRLF?

Should I be concerned about this in the long run or just ignore it and keep going as I usually do?

2 Answers 2

In Unix systems the end of a line is represented with a line feed (LF). In windows a line is represented with a carriage return (CR) and a line feed (LF) thus (CRLF). when you get code from git that was uploaded from a unix system they will only have an LF.

If you are a single developer working on a windows machine, and you don’t care that git automatically replaces LFs to CRLFs, you can turn this warning off by typing the following in the git command line

If you want to make an intelligent decision how git should handle this, read the documentation

Here is a snippet

Formatting and Whitespace

Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It’s very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. Git has a few configuration options to help with these issues.

If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.

If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false:

Что такое LF, CLRF и как с этим бороться?

Не холивара ради, но накипело.
Вот наизобретали — фреймворки, галпы, гиты, баши. mvc solid — что черт ногу сломит.

вместо двух-трех страниц говнокода — нужно наплодить хренову тучу конфигов, папок, что через неделю работы уже ничерта не помнишь где что лежит, а половину файлов вообще никогда не открывал.

я знал, что рано или поздно мне тупо надоест вся эта тягомутина..

внимание вопрос:
раз все такие мега-супер разработчики, кодеры, программеры — так какого лешего, чтобы эти супер удобные изобретения заработали — нужно задать двести вопросов на всех сайтах? а если проще, какого рожна они не работают нормально изначально?? и не надо про прямые-кривые руки.

собственно чего взбесилася я:
Решил я сделать чистую болванку laravel-проекта на 5.1 версии (оттуда всякие базовые плюшки — в виде авторизации, базовых вьюшек повырезали), с прикрученной админкой, ну в общем чтобы быстро это все развернуть.

подумал — ну а чего я мамонт освоил фреймворки! галпы, ноды, пакет для лава, тьфу ларавела написал, а гитхабом не умею пользоваться.
установил. опять форт-баярд — это жми, это не жми.

и в итоге после git init, git add . — получаю 500 тыщ строчек:
the file will have its original line endings..
warning: LF will be replaced by CRLF in.

ну вот какого рожна? это еще тратить время вникая, что это — чем грозит, как избавиться, надо ли. или еще надо 20 пакетов установить?

вместо реальной разработки я последнюю неделю только и делаю, что что-то устанавливаю, что 100% упростит мне жизнь. а вместо этого я уже забыл что такое css и верстка — ибо только и делаю, что подгоняю! под кем-то вымышленные станадарты. а когда ты вроде бы «фухх оно работает» — получаешь в ответ, что «нет блин. принцип инъекции или индукции или единственной безответственности нарушен»

короче что-то мне подсказывает, что тот дядька, чей-то шеф, который заставил писать на процедурном, без всяких mvc и фреймворков — прав.

и эта. все-таки — LF и CLRF это смертельно?

П.с. я вчера в ночи поставил вин 10 все-таки. не нарадуюсь. 4.9 из 5!

Windows git “warning: LF will be replaced by CRLF”, is that warning tail backward?

Wheng I git commit , it says:

Is this warning tail backward?
I edit file in Windows, the end of line is CRLF , just like this pic:

And git changes it to LF for committing to repo.
So I think the correct warning is:

8 Answers 8

warning: LF will be replaced by CRLF.

Depending on the editor you are using, a text file with LF wouldn’t necessary be saved with CRLF: recent editors can preserve eol style. But that git config setting insists on changing those.

Simply make sure that (as I recommend here):

That way, you avoid any automatic transformation, and can still specify them through a .gitattributes file and core.eol directives.

windows git «LF will be replaced by CRLF»
Is this warning tail backward?

No: you are on Windows, and the git config help page does mention

Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings.

As described in «git replacing LF with CRLF», it should only occur on checkout (not commit), with core.autocrlf=true .

As mentioned in XiaoPeng’s answer, that warning is the same as:

warning: (If you check it out/or clone to another folder with your current core.autocrlf configuration,) LF will be replaced by CRLF
The file will have its original line endings in your (current) working directory.

I still feel this message is confusing, the message could be extended to include a better explanation of the issue, for example: «LF will be replaced by CRLF in file.json after removing the file and checking it out again».

Note: Git 2.19 (Sept 2018), when using core.autocrlf , the bogus «LF will be replaced by CRLF» warning is now suppressed.

As quaylar rightly comments, if there is a conversion on commit, it is to LF only.

That specific warning » LF will be replaced by CRLF » comes from convert.c#check_safe_crlf():

And that last renormalize_buffer() is only called by merge-recursive.c#blob_unchanged() .

So I suspect this conversion happens on a git commit only if said commit is part of a merge process.

Note: with Git 2.17 (Q2 2018), a code cleanup adds some explanation.

convert_to_git(): safe_crlf/checksafe becomes int conv_flags

When calling convert_to_git() , the checksafe parameter defined what should happen if the EOL conversion ( CRLF —> LF —> CRLF ) does not roundtrip cleanly.
In addition, it also defined if line endings should be renormalized ( CRLF —> LF ) or kept as they are.

checksafe was an safe_crlf enum with these values:

Note that a regression introduced in 8462ff4 (» convert_to_git() : safe_crlf/checksafe becomes int conv_flags «, 2018-01-13, Git 2.17.0) back in Git 2.17 cycle caused autocrlf rewrites to produce a warning message despite setting safecrlf=false .