Solving Git LF will be replaced by CRLF
This make git status show every file change. All files in repos are in red.
when you try to see the diff
What we want is only CRLF to make the code work on our Window workspace and LF elsewhere.
The fix is by use autocrlf
You won’t see it work unless you delete and clone the repos again or restart the index by
What does it do?
From the git document here.
“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 file system.”
In short, when code enter your machine git add CR . When you add file by git, git strip off CR .
Git — LF Will Be Replaced by CRLF
LF stands for Line Feed which is a way to represent the end of a line in UNIX-based systems. But in a Windows-based system, a line is usually expressed by CR (Carriage Return) and a line feed (LF).
This problem arises if you use UNIX based system (macOS) to push code, the code will have an LF ending.
If you use a windows machine, make modifications to the code, and do commit, it will be replaced by CRLF since git is smart and does not expect you to use LF on Windows OS.
Similarly, the opposite happens if the warning says, CRLF will be replaced by LF . You will lose windows based CRLF after commit/checkout, and LF will replace it.
Fix LF Will Be Replaced by CRLF Warning in Git
One way to fix the warning is to make changes in config files located in the path where git is installed. The value of code.autocrlf is stored in gitconfig file located at %ProgramFiles(x86)%\git\etc\gitconfig or ProgramFiles\git\etc\gitconfig and in /etc/gitconfig in Linux/Unix based operating systems.
However, we can fix the issue in different situations:
If you wish to use the project on Unix based OS, you should set the value of core.autocrlf to true
If you wish to use the project under Windows only, the flag should be set to false .
However, in Unix-based OS, you can disable the core.autocrlf per our need.
Before making modifications, you can check the current settings by using the following command,
The command will give output of true or false or input , and you can make changes according to your need.
Fix LF Will Be Replaced by CRLF Warning on the Whole System
To fix the issue systemwide, you can use,
Fix LF Will Be Replaced by CRLF Warning Per User
To fix the issue according to the user, you can use,
Fix LF Will Be Replaced by CRLF Warning on the Project Only
To fix the issue for a particular project,
Ashok is an avid learner and senior software engineer with a keen interest in cyber security. He loves articulating his experience with words to wider audience.
How to Fix LF Will Be Replaced by CRLF Warning in Git
This article will discuss the “warning: LF will be replaced by CRLF” and provide the solution to fix it.
What is “warning: LF will be replaced by CRLF” in Git?
The “warning: LF will be replaced by CRLF” mostly occurs when the value of the Git configuration variable is settled as “true”. The reason behind the warning is that the committed files are different from what you saved.
So, to resolve or avoid this warning, you have to change the value of the Git configuration variable using the “$ git config <–global or local> core.autocrlf false” command.
Check out the below-given scenario, which shows us the specified warning.
Step 1: Navigate to Git Folder
First, move to the Git projects root folder using provided command:
Step 2: Create and Move to Git Local Repository
Create a new directory by executing the “mkdir” command and immediately move to it utilizing “cd” command:
Step 3: Initialize Git Repository
Now, run the “git init” command to initialize the Git local repository:
Step 4: Open and Update File
Run the provided command to create a new file and add some text using the redirect operator:
Here, we have added “It’s my first file” text in “file1.txt” through “echo” command:
Step 5: Add File
Next, add the file to the Git staging area using below command:
It can be seen that Git bash threw the mentioned warning when we tried to add the file to the staging area:
Now, let’s move to the next section to fix the “warning: LF will be replaced by CRLF”.
How to Fix “warning: Lf will be replaced by CRLF”?
Now, let’s move toward the below-provided steps to fix the stated warning encountered in the previous section.
Step 1: Check Settings
First, check the default settings of the Git configuration variable value using the provided command:
According to the below output, the Git configuration variable is set as “true”:
Step 2: Replace by CRLF Warning Globally(Per User)
Next, we will change the value of the Git configuration variable to “false” with the help of given command:
Step 3: Verify Settings
Now, we will verify the performed operation to ensure the configuration variable value is changed to “false”:
Below-output indicates that the variable value is successfully set to “false”:
Step 4: Replace by CRLF Warning Locally(For the Project Only)
To replace the CRLF warning for the specific local projects, execute the below provided command:
Step 5: Verify Settings
Now, we will run the “git config” command with “core.autocrlf” Git configuration variable to check its configured value:
In the below output, you can see that value is successfully settled to “false”:
Step 6: Add File
Finally, we will add the file to the Git staging area with the help of the given command:
It can be seen that; the file is added successfully:
Step 7: Check Status
Lastly, we will check the Git repository’s current status:
The below output indicates that the new file is added to the Git repository:
That’s it! We have provided the simplest solution to fix the CRLF warning in Git.
Conclusion
Git users mostly encounter the “warning: LF will be replaced by CRLF” when the “autocrlf” Git configuration variable value is configured as “true”. However, you can change its value as “global” per user as well as “local” per project in the “$ git config <–global or local> core.autocrlf false” command. In this article, we have discussed the “warning: LF will be replaced by CRLF” and offered the solutions to fix it.
About the author
Maria Naz
I hold a master’s degree in computer science. I am passionate about my work, exploring new technologies, learning programming languages, and I love to share my knowledge with the world.
Git for Windows: работа с параметром core.autocrlf
Я работаю в операционной системе «Windows 10». У меня на компьютере установлена программа «Git for Windows» версии 2.35.1. В принципе, «Git for Windows» — это та же знаменитая программа (набор программ) «Git» (система управления версиями), только скомпилированная из исходного кода в исполняемый файл, который может запускаться в операционных системах «Windows» (изначально исходный код «Git» был написан для компиляции в исполняемый файл, запускаемый в операционной системе «Linux»).
Дистрибутив «Git for Windows» кроме программы «Git» содержит разные полезные для работы с «Git» программы, вроде программы-оболочки «Git Bash» с интерфейсом командной строки и программы «Git GUI» с графическим оконным интерфейсом. В документации сказано, что «Git for Windows» является подмножеством платформы (набора инструментов и библиотек) «MSYS2». Как я понимаю, для компиляции используется компилятор из набора инструментов «MinGW-w64».
Окончания строк в разных операционных системах
Как известно (возможно, не всем), в операционных системах «Windows» окончание строки обычно представляется двумя символами, в таблице Юникода они обозначены кодами U+000D (возврат каретки, по-английски «Carriage Return», сокращенно «CR») и U+000A (подача бумаги на следующую строку, по-английски «Line Feed», сокращенно «LF»). В мир компьютеров эти управляющие коды пришли из мира печатных (пишущих) машинок.
В Unix-подобных операционных системах окончание строки обычно представляется одним символом «LF». (Говорят, в операционных системах от компании «Apple» до появления операционной системы «Mac OS X», которая вышла в 2001 году, окончание строки представлялось одним символом «CR». Сейчас в операционных системах «macOS» окончание строки представляется одним символом «LF», как и в других Unix-подобных операционных системах.)
Из-за того, что большинство текстовых редакторов (даже заточенных под написание текстов программ) плохо умеет работать с окончаниями строк разного вида, вышеописанная разница приносит проблемы, если над одним и тем же проектом работают программисты из разных операционных систем.
Я подготовил для экспериментов текстовый файл, содержащий несколько строк с окончаниями разного вида. Для работы с кодом я обычно использую программы «VS Code» и «Notepad++». Обе эти программы могут правильно отображать строки с окончаниями разного вида. Однако, программа «VS Code» не отображает отдельные символы, входящие в окончания строк, поэтому в ней не получается понять, где и какое окончание строки использовано. Для просмотра и определения видов окончаний строк я обычно использую программу «Notepad++», она умеет отображать отдельные символы, входящие в окончания строк. Вот как у меня на компьютере выглядит в программе «Notepad++» тестовый файл «myfile.txt» (включено отображение всех символов, то есть и тех, которые обычно не отображаются в текстовых редакторах):
На иллюстрации выше видно, что две строки имеют окончания в виде пары символов CR и LF (эту пару символов часто обозначают как «CRLF»), а другие две строки — в виде LF. В программе «Notepad++» у меня не получилось создать разные виды окончаний строк в одном и том же файле (хотя можно скопировать и вставить существующие с помощью инструмента специальной вставки), поэтому я сначала ввел текст файла в программе «Notepad++» с одинаковыми окончаниями строк, а потом подправил два из этих окончаний строк в шестнадцатеричном (двоичном) редакторе. Кодировка файла «myfile.txt» — UTF-8 (как видно на иллюстрации, размер файла — 222 байта, русские буквы занимают по два байта).
Также на иллюстрации выше видно, что в строке состояния программы «Notepad++» режим работы с окончаниями строк показан как «Windows (CR LF)». Этот режим не влияет на отображение символов только что открытого файла. Он лишь говорит о том, что при вставке нового окончания строки (нажатием клавиши «Enter») будет вставлено окончание строки вида CRLF. Этот режим можно переключить на «Unix (LF)» или на «Macintosh (CR)», после чего можно будет клавишей «Enter» вставлять окончания строк вида LF или CR. Однако, переключение этого режима не дает возможности работать в одном файле одновременно с несколькими видами окончаний строк, так как при переключении этого режима меняются сразу все окончания строк в файле на выбранный в режиме вид окончаний строк.
Тестовый файл «myfile.txt» я разместил в папке C:\Users\Илья\source\repos\test\ . Пока он в этой папке один. Будем считать эту папку папкой нашего проекта.
Создание Git-репозитория и параметр «core.autocrlf»
С программой «Git» можно работать множеством способов, но я предпочитаю самый универсальный — из командной строки. Для этого я обычно использую программу-оболочку «PowerShell» версии 7, а запускаю ее в программе-«эмуляторе терминала» «Windows Terminal». Итак, проверим, что программа «Git» установлена на компьютере и доступна в папке нашего проекта:
Создадим Git-репозиторий для нашего проекта:
«Репозиторием» обычно называют папку (хранилище, базу данных), в которой хранится исходный код программы (папку проекта). А «Git-репозиторием» называют базу данных, в которой хранятся разные версии файлов нашего проекта, информация о них и об изменениях, вносимых в эти файлы. Сама программа (система программ) «Git» у меня установлена в папке C:\Program Files\Git\ . Чтобы обеспечить управление версиями файлов нашего проекта, в папке нашего проекта с помощью вышеприведенной команды была создана скрытая папка «.git» (у меня в программе «Проводник Windows» включено отображение скрытых папок, поэтому ее там видно), в которой хранятся база данных с версиями файлов нашего проекта и разные служебные файлы.
Сразу после создания папки «.git» в ней уже есть файлы базы данных и разные служебные файлы. Но пока что эта база данных пуста (пока еще не содержит версий файлов нашего проекта). Чтобы файлы нашего проекта попали под отслеживание в них изменений от программы «Git», они должны быть добавлены в базу данных в папке «.git» посредством коммитов («коммит» — это операция регистрации изменений в файлах проекта).
Настройка работы программы «Git» может быть произведена на трех разных уровнях: на уровне операционной системы (для всех ее пользователей), на уровне отдельного пользователя (global) и на уровне проекта (local). При установке программы «Git» программа-установщик обычно задает умолчательные настройки на уровне текущего пользователя операционной системы. В рамках данного поста мы затронем только настройки на уровне текущего проекта, они хранятся в файле \.git\config (этот файл не имеет расширения) текущего проекта. Этот файл был создан в результате вышеприведенной команды «git init», он — текстовый, но нет нужды редактировать его вручную, для этого есть отдельная команда «git config».
Если какой-либо параметр не определен в вышеупомянутом файле настроек текущего проекта, то значение этого параметра будет автоматически взято из файла настроек текущего пользователя операционной системы. Для чистоты эксперимента мы будем прямо прописывать нужное значение нужного параметра в файле настроек текущего проекта с помощью следующей команды:
Как работает параметр «core.autocrlf» мы проверим экспериментально, после чего станет понятно, для чего этот параметр можно использовать.
1. Параметр «core.autocrlf», значение «true»
Итак, с помощью команды, приведенной выше, мы установили для параметра «core.autocrlf» значение «true». Совершим первый коммит, в который включим текущую версию нашего тестового файла «myfile.txt»:
В блоке кода выше приведены сразу две команды подряд. Команда «git add» формирует список содержимого будущего коммита. Когда содержимое коммита сформировано, делаем сам коммит (регистрацию изменений в коде программы в базе данных в папке «.git» нашего проекта) с помощью команды «git commit».
Два сообщения, выданные после первой команды в блоке кода выше, могут запутать неопытного пользователя. Первое сообщает о том, что окончания строк вида LF будут заменены окончаниями строк вида CRLF в нашем тестовом файле «myfile.txt». Второе сообщает, что версия файла «myfile.txt», находящаяся в папке проекта, сохранит окончания строк в оригинальном виде. На первый взгляд, эти сообщения противоречат друг другу. Путаница возникает из-за того, что в обоих сообщениях употреблено будущее время, но не уточняется, что события, о которых идет речь, хоть и произойдут в будущем, но произойдут НЕ одновременно.
На самом деле, во втором сообщении имеется в виду, что оригинальные окончания строк в файле «myfile.txt» останутся нетронутыми работой запущенной команды «git add». А первое сообщение предупреждает о том, что в будущем, после извлечения версии файла «myfile.txt» из базы данных в папку проекта, окончания строк вида LF будут затерты окончаниями строк CRLF из-за текущего значения настройки «core.autocrlf».
Проверим это на практике. После окончания работы двух команд, показанных в блоке кода выше, я заглянул в файл «myfile.txt», находящийся в папке проекта (в терминах программы «Git» ее называют «рабочей папкой» [working directory], так как именно тут мы работаем с файлами проекта, вносим в них изменения), и убедился, что окончания строк в нем остались без изменений (две строки с окончаниями вида CRLF, две строки с окончаниями вида LF). То есть обещание «The file will have its original line endings in your working directory» сбылось.
После этого я удалил файл «myfile.txt» из папки проекта в корзину операционной системы. Представим, что я потерял рабочие файлы своего проекта. Восстановим их (конкретно в нашем проекте один файл, но в общем случае их может быть много) в папку проекта из базы данных, созданной ранее средствами программы «Git» для нашего проекта:
В результате этой команды в папке проекта снова появился файл «myfile.txt». Однако, все четыре окончания строк в этом файле теперь стали одного вида: CRLF. Сбылось обещание из предупреждения «warning: LF will be replaced by CRLF in myfile.txt.».
Как работает настройка «core.autocrlf» со значением «true»? Если при такой настройке мы помещаем версию измененного файла в базу данных «Git» данного проекта, то все найденные в этом файле окончания строк вида CRLF конвертируются в окончания строк вида LF. Если при такой настройке мы извлекаем версию файла, хранящуюся в базе данных «Git» данного проекта, то все найденные в этой версии файла окончания строк вида LF конвертируются в окончания строк вида CRLF. Вот как это можно показать схематично:
Подчеркну, что на этой схеме внесение в базу данных (коммит) и извлечение из нее (checkout) разнесены во времени. Если внесение в базу данных произошло при настройке «core.autocrlf» со значением «true», а извлечение из базы данных произошло при настройке «core.autocrlf» со значением «false», то конвертация при извлечении не произойдет и все четыре окончания строк в извлеченном файле окажутся вида LF (в том виде, в котором этот файл был помещен в базу данных и хранится там). Это замечание может быть сходным образом применено и к другим значениям настройки «core.autocrlf».
2. Параметр «core.autocrlf», значение «false»
Схема работы при такой настройке:
При такой настройке в базе данных «Git» будет храниться именно то, что мы туда положили. И будет извлечено именно то, что хранится в базе данных, без изменений.
3. Параметр «core.autocrlf», значение «input»
Схема работы при такой настройке:
Зачем нужны эти три настройки
Параметр «core.autocrlf» со значением «false» — это естественный режим работы программы «Git», который использовался бы, если б не было разницы в представлении окончаний строк в разных операционных системах.
Собственно, параметр «core.autocrlf» придумали для обеспечения работы над одним проектом программистов из разных операционных систем. Предполагается, что программист в операционной системе «Windows» будет работать с файлами, в которых окончания строк только вида CRLF. При этом предполагается, что он включит для проекта настройку «core.autocrlf» со значением «true». Тогда он будет работать в своей папке проекта с файлами, в которых окончания строк будут вида CRLF, при этом в базе данных «Git» эти же файлы будут сохранены с окончаниями вида LF. Программист в операционной системе «Windows» этого даже не заметит, ведь конвертация происходит автоматически, как было показано выше в пункте 1.
В тот же момент программист в Unix-подобной операционной системе будет работать с той же базой данных «Git», но у него для проекта будет включена настройка «core.autocrlf» со значением «input» (или со значением «false»). Он будет получать из базы данных файлы с окончаниями строк вида LF, как и принято в Unix-подобных операционных системах.
В принципе, программист в операционной системе «Windows» тоже может использовать параметр «core.autocrlf» со значением «false» в случае, если он работает со своей базой данных «Git» один и пишет код только для операционных систем Windows. Либо он работает вместе с другими программистами, но все участники проекта работают в операционных системах «Windows» и проект предназначен только для операционных систем «Windows». Либо, еще один вариант, в коде есть файлы с окончаниями строк разного вида (CRLF и/или LF) и программист хочет сам отслеживать виды окончаний строк в своих файлах, без вмешательства программ, без автоматической конвертации.
Полезные ссылки
В книге «Pro Git» (вторая редакция, вышла в 2014 году), авторы: Scott Chacon (Скотт Чакон) и Ben Straub (Бен Страуб), в главе 8 «Настройка Git», в подглаве 8.1 «Конфигурация Git» (статья большая, ищите в ее последней трети раздел «Форматирование и пробелы»).
Хороший, развернутый ответ на вопрос «Git replacing LF with CRLF» на известном сайте «Stack Overflow».