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
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:
Our team members are Linux/Mac platforms and participate in the project's git commits
Some software on Windows platform will generate code text whose line breaks are LF (such as Webstorm, etc.)
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
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.
When set to false, git will not do the conversion. The text file remains as it is.
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.
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=trueby default (you can use the
git config core.autocrlfcommand to query whether this property is true by default on Windows. If it is not true, pass
config --global core.autocrlftrue
command sets this property to true), andcore.autocrlf=true` has the following 3 functions to avoid errors:
Git automatically converts LF to CRLF on
git addand gives that warning LF will be replaced by CRLF
Git automatically converts CRLF to LF on
Git automatically converts LF to CRLF on
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.
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