Warning lf will be replaced by crlf in что это
а потом бум! Я вижу, что это всплывает почти для всех файлов. Обычно я просто продолжаю работать и создаю свое приложение, и оно исчезает после многих изменений в файлах.
пример:
файл будет иметь исходные окончания строк в вашем рабочем каталоге. предупреждение: LF будет заменен CRLF в Gemfile.
файл будет иметь исходные окончания строк в вашем рабочем каталоге. предупреждение: LF будет заменен CRLF в Gemfile.замок.
файл будет иметь исходные окончания строк в вашем рабочем каталоге. предупреждение: LF будет заменен CRLF в README.
в чем разница между LF и Эти символы не экранируются?
должен ли я беспокоиться об этом в долгосрочной перспективе или просто игнорировать его и продолжать идти, как я обычно делаю?
2 ответов:
в системах Unix конец строки представляется с подачей строки (LF). В windows строка представляется с возвратом каретки (CR) и подачей строки (LF) таким образом (CRLF). когда вы получаете код от git, который был загружен из системы unix, у них будет только LF.
если вы хотите отключить это предупреждение, введите его в командной строке git
если вы хотите принять разумное решение, как git должен справиться с этим,читать документацию
форматирование и пробелы
форматирование и пробелы проблемы являются одними из наиболее неприятных и тонкие проблемы, с которыми сталкиваются многие разработчики при совместной работе, особенно кросс-платформенный. Это очень легко для патчей или других совместная работа по внедрению тонких изменений пробелов, потому что Редакторы молча представляют их, и если ваши файлы когда-либо касались Системы Windows, их линия окончания могут быть заменены. В Git есть несколько параметры конфигурации, чтобы помочь с этими проблемами.
если вы программируете на Windows и работаете с людьми, которые не являются (или наоборот), вы, вероятно, столкнетесь с проблемами с окончанием строки в некоторых случаях точка. Это связано с тем, что Windows использует оба символа возврата каретки и символ перевода строки для новых строк в своих файлах, тогда как Mac и В системах Linux используется только символ перевода строки. Это тонкий, но невероятно раздражает факт кросс-платформенной работы; многие редакторы на Windows молча заменяет существующие окончания линий в стиле LF на CRLF, или вставьте оба символа конца строки, когда пользователь нажимает клавишу enter.
Git может справиться с этим путем автоматического преобразования окончаний CRLF линии в LF, когда добавить файл в индекс, и наоборот, когда он проверяет код на вашу файловую систему. Вы можете включить эту функцию с ядро.установка autocrlf. Если вы находитесь на компьютере с Windows, установите для него значение true – этот преобразует LF концовки в CRLF, когда вы проверяете код:
если вы находитесь в системе Linux или Mac, которая использует LF-окончания строк, то вы не хочу, чтобы Git автоматически конвертировал их при извлечении файлов; однако, если файл с окончаниями CRLF случайно вводится, тогда Вам может понадобиться Git, чтобы исправить это. Вы можете сказать, Git, чтобы преобразовать переводы строк в LF на фиксации, но не наоборот, установив ядро.autocrlf to вход:
настройка должен оставить вас с окончаниями CRLF в Windows checkouts, но LF-окончания на системах Mac и Linux и в репозитории.
если вы программист Windows, выполняющий проект только для Windows, то вы можно отключить эту функцию, записывая возврат каретки в репозиторий, установив значение конфигурации в false:
Столкнулся с этим впервые, другой проект нормально залился в репозиторий.
Вот порядок действий:
Захожу в локальную папку проекта
cd
Инициализирую гит
git init
И тут он пишет мне:
warning: LF will be replaced by CRLF in *file_name*
The file will have its original line endings in your working directory.
После чего выполняю коммит и он пишет:
В гите новичок. Гуглил, способы решения не подошли.
Инициализируем новый репозиторий
git init
Если файлы не добавляются, то добавляем каждый вручную
git add README.md
warning: LF will be replaced by CRLF in *file_name*
The file will have its original line endings in your working directory.
В GitBash (Windows)
Пишет что заменит LF на CRLF (will be):
Но он не делает этого:
Или он изменяет это в слепках файлов проекта?
Связанно это с тем что переносы строк были в Unix-формате, так как дело происходило под Windows.
Простые решения:
Очень просто конвертировать переносы строк в Windows-формат помогает текстовый редактор Notepad++: Правка→EOL конверсия→Преобразовать в WIN-формат.
Подробнее.
Вручную преобразовать символы перевода строки из виндовых в линуксовые, открыть файл, еще раз визуально все проконтролировать и сохранить.
Быстро заменить CRLF на LF можно утилитой dos2unix, входящей в MINGW, с которым поставляется git для win32:
InterMaster.com.ru
О бизнесе в интернете, отдыхе в реале и просто о жизни…
Как я меняю в проектах концы строк с CRLF на LF
Иногда бывает такая ситуация – получаешь от заказчика движок для его дальнейшего «допиливания». Пытаешься положить его в репозиторий Git – и получаешь кучу варнингов типа:
Небольшая справка для тех, кто не в курсе. В разных операционных системах принят разный формат символов, обозначающий перевод строк:
Теперь опишу свой способ приведения конца строк к единому виду. Описывать работу буду на примере графической оболочки Git – Git GUI. Так проще и нагляднее.
или выполнить команды:
Первый параметр дает команду Git заменить все окончания строк с CRLF в LF при записи в репозиторий.
Теперь движок можно класть в репозиторий Git. И не забудьте в редакторе, которым выпотом будете править файлы, выставить по умолчанию концовку строк LF, чтобы опять не возникла мешанина.
Еще записи по теме
Admin: да, можно в каждом файле отдельно формат концов строк поменять. Но т.к. файлов очень много, то пока не придумал ничего лучше такого вот «пакетного» изменения сразу во всех файлах.
Спасибо. Долго искал. Изощрённый метод однако
Как раз с данной ошибкой (LF will be replaced by CRLF ) столкнулся, но смотрю что в Нетбинсе «Правка»->»Замена», выбираем что регулярка и пишем с \r\n на \n и оно во всех файлах приведет к линуксовскому виду, ну типа того что вы добились гитом
Все тоже самое что и в статье, только проще, в Notepad++
CTRL-F >> ‘Найти в файлах’
1. Выбираем ‘Режим поиска’ >> ‘Расширенный’
2. В поле ‘Папка’ выбираем папку с проектом
3. В поле ‘Найти’ пишем ‘\r\n’
4. В поле ‘Заменить на’ пишем ‘\n’
5. Жмем ‘Заменить в файлах’
6. После замены возвращаемся к шагу #3 и пишем ‘\r’, жмем заменить
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
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:
Windows git «warning: LF will be replaced by CRLF», is that warning tail backward?
12 Answers 12
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):
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 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».
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():
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
checksafe was an safe_crlf enum with these values: