Lf will be replaced by crlf in ошибка

These messages are due to an incorrect default value of core.autocrlf on Windows.

The concept of autocrlf is to handle line endings conversions transparently. And it does!

Bad news: the value needs to be configured manually.

Good news: it should only be done one time per Git installation (per project setting is also possible).

How autocrlf works:

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

     repository               repository               repository
      ^      V                 ^      V                 ^      V
     /                       /                       /        
crlf->lf    lf->crlf     crlf->lf                    /          
   /                       /                       /            

Here crlf = win-style end-of-line marker, lf = unix-style (also used on Mac since Mac OS X).

(pre-osx cr is not affected for any of three options above.)

When does this warning show up (under Windows)?

    – autocrlf = true if you have unix-style lf in one of your files (= RARELY),
    – autocrlf = input if you have win-style crlf in one of your files (= almost ALWAYS),
    – autocrlf = false – NEVER!

What does this warning mean?

The warning «LF will be replaced by CRLF» says that you (having autocrlf=true) will lose your unix-style LF after commit-checkout cycle (it will be replaced by windows-style CRLF). Git doesn’t expect you to use unix-style LF under Windows.

The warning «CRLF will be replaced by LF» says that you (having autocrlf=input) will lose your windows-style CRLF after a commit-checkout cycle (it will be replaced by unix-style LF). Don’t use input under Windows.

Yet another way to show how autocrlf works

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

where x is either CRLF (windows-style) or LF (unix-style) and arrows stand for

file to commit -> repository -> checked out file

How to fix

The default value for core.autocrlf is selected during Git installation and stored in system-wide gitconfig (%ProgramFiles(x86)%gitetcgitconfig on Windows, /etc/gitconfig on Linux). Also there’re (cascading in the following order):

   – «global» (per-user) gitconfig located at ~/.gitconfig, yet another
   – «global» (per-user) gitconfig at $XDG_CONFIG_HOME/git/config or $HOME/.config/git/config and
   – «local» (per-repo) gitconfig at .git/config in the working directory.

So, write git config core.autocrlf in the working directory to check the currently used value and

   – git config --system core.autocrlf false            # per-system solution
   – git config --global core.autocrlf false            # per-user solution
   – git config --local core.autocrlf false              # per-project solution

Warnings

    – git config settings can be overridden by gitattributes settings.
    – crlf -> lf conversion only happens when adding new files, crlf files already existing in the repo aren’t affected.

Moral (for Windows):

    — use core.autocrlf = true if you plan to use this project under Unix as well (and unwilling to configure your editor/IDE to use unix line endings),
    — use core.autocrlf = false if you plan to use this project under Windows only (or you have configured your editor/IDE to use unix line endings),
    — never use core.autocrlf = input unless you have a good reason to (eg if you’re using unix utilities under Windows or if you run into makefiles issues),

PS What to choose when installing Git for Windows?

If you’re not going to use any of your projects under Unix, don’t agree with the default first option. Choose the third one (Checkout as-is, commit as-is). You won’t see this message. Ever.

PPS: My personal preference is configuring the editor/IDE to use unix-style endings, and setting core.autocrlf to false.

Update(2022)

Since 2018, git can —renormalize repo fixing the existing line endings as required.

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

git config core.autocrlf true

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.

core.autocrlf

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:

$ git config --global core.autocrlf true

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:

$ git config --global core.autocrlf 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:

$ git config --global core.autocrlf false

Hi @uuuser-name

I recently got the same error message from git on MacOS.
Here is my understanding of the problem and how I fixed this issue.

Why?

Git refuses to commit any text file when the CR+LF to LF configuration would generate something not reversible.
Here is the long story: http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Workaround

# Replace all CR+LF with LF (keeping dates unchanged)
find .obsidian/plugins -type f | xargs dos2unix -k

git add .obsidian

If you do not have dos2unix you can install with brew (a package manager), like so:
brew install dos2unix

Solution

The ideal solution IMHO would be for plugin authors to use the following git configuration:

On Windows: git config --global core.autocrlf true
When committing a text file to the repository git replaces CR+LF with LF.
When checking out a text file from the repository git replaces LF with CR+LF.

Working Directory =========> Repository
                              CRLF ==> LF 

Working Directory <========= Repository
                              CRLF <== LF 

On Linux and MacOS: git config --global core.autocrlf input
When committing a text file to the repository git replaces CR+LF with LF.
When checking out a text file from the repository git does not do any replacement.

Working Directory =========> Repository
                              CRLF ==> LF 

Working Directory <========= Repository
                              No Change 

So that the text files end up with LF (instead of CR LF) when committed to the repository.

Sources

• https://stackoverflow.com/q/3206843/386517
• http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
• https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings

Перейти к содержимому

 $ git config --global core.autocrlf false

Resolved: Git warning LF will be replaced by CRLF in file

git config core.autocrlf true

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)%gitetcgitconfig or ProgramFilesgitetcgitconfig 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,

git config --system core.autocrlf false

Fix LF Will Be Replaced by CRLF Warning Per User

To fix the issue according to the user, you can use,

git config --global core.autocrlf false

Fix LF Will Be Replaced by CRLF Warning on the Project Only

To fix the issue for a particular project,

git config --local core.autocrlf false