Analyse warning LF will be replaced by CRLF in xxx

Sometimes we have this situation:

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

analyze

Literally: Warning: In xxx file, LF will be replaced by CRLF.

The file will have its original line endings in your working directory. Obviously, the problem is that the line breaks used by different operating systems are different. Generally, there are two situations that cause this problem:

1. Our team members are Linux/Mac platforms and participate in the project's git commits

2. Some software on Windows platform will generate code text whose line breaks are LF (such as Webstorm, etc.)

附上换行符相关知识

Info

Uinx/Linux uses the newline character LF to indicate the next line (LF: LineFeed, which means newline in Chinese, ie "\n")

Dos and Windows use carriage return + line feed CRLF to indicate the next line (CRLF: CarriageReturn LineFeed, Chinese means carriage return and line feed, that is, "\r\n")

Mac OS only uses a line feed (LF) character to end a line. The early Mac OS used carriage return CR to indicate the next line (CR: CarriageReturn, Chinese means carriage return, and later Mac also defected to unix)

git handles newlines

In Git, you can use the following commands to display/set which way your Git currently treats newlines

git config core.autocrlf ture/false/input

1. When set to true, this means that any time you add a file to a git repository, git will treat it as a text file. It will turn crlf into LF.

2. When set to false, git will not do the conversion. The text file remains as it is.

3. When set to input, when adding files to the git repository, git turns crlf into lf. When someone checks the code, it is still in the lf newline format. Therefore, under the windows operating system, do not use this setting.

Solution

1.If you are currently on a Window platform and this warning appears, do nothing. Although this warning is ugly, this warning can ensure that the project team operates the code across the system git normally.

• Because the Windows client of git basically sets core.autocrlf=true by default (you can use the git config core.autocrlf command to query whether this property is true by default on Windows. If it is not true, pass config --global core.autocrlf truecommand sets this property to true), andcore.autocrlf=true` has the following 3 functions to avoid errors:

  • Git automatically converts LF to CRLF on git add and gives that warning LF will be replaced by CRLF

  • Git automatically converts CRLF to LF on git commit

  • Git automatically converts LF to CRLF on git checkout/switch or git clone

  2.If we are on a Linux or Mac platform, there is no need for "Git automatically converts LF to CRLF on git checkout/switch or git clone". However, you definitely want Git to fix when a file with CRLF as a line terminator is accidentally introduced on Linux or Mac platforms. So, you can tell Git to convert CRLF to LF on commit by setting core.autocrlf to input via config --global core.autocrlf input command, but not on git checkout.

Through the above two schemes, CRLF will be retained in the checkout file on Windows, while LF will be retained in Mac and Linux, as well as in the version library, so as to ensure the normal cross-system git operation code of the project team.

Warning

Why pay attention to this issue, as this issue has some negative effects:

• If you're writing programs on Windows, or if you're working with other people who are programming on Windows and you on other systems, in these cases you may have end-of-line terminator problems. The full negative effects of this issue are as follows:

• One of the most direct consequences is that if a multiline text file under Unix/Mac system is opened in Windows, multiline text will become one line. (Reason: Unix/Mac only uses the newline character '\n', and Windows' newline requirement is the carriage return linefeed character '\r\n', so the newline of "multi-line text" in Unix/Mac does not conform to Windows rules, so Windows treats these multi-line texts that do not conform to the newline rules as if they have no newlines, so the multi-line text will become one line)

• If the file in Windows is opened under Unix/Mac, there may be an extra ^M symbol at the end of each line

• If the file saved in Linux is viewed with Notepad on Windows, there will be black dots