Before I solve your problem, I need to say a few more words. When you are collaborating on code development with others through GitHub or other remote hosting servers, it is important to ensure that line breaks are handled correctly. First of all, you need to know that different operating systems have different definitions of newline characters. The newline character in Unix or Unix-like operating systems is called LF, while the newline character in Windows systems is called CRLF. There is a big difference between the two:

In Unix system, the end of each line is only "<line feed>", which is "n"; in Windows system, the end of each line is "<line feed><carriage return>"

Note: Quoted from the difference between carriage return (CR) and line feed (LF), 'r' and 'n'.

This is the root of the problem - that is, if you are using a Windows system and your friend is using a Mac, when you use git to collaboratively develop software, there will be a problem of inconsistent line breaks.

Git can actually handle the problem of inconsistent line breaks by itself, but it may produce unexpected results. Therefore, it is necessary to make relevant settings. Generally, if you don’t want to bother, you can use the common methods, as shown below:

$ git config --global core.autocrlf true

In fact, when you installed the Windows version of git or togoiseGit, you may have already made such a configuration. Maybe you didn't know it at the time. For example, the reason why the poster generated such a warning:

warning: LF will be replaced by CRLF in...

It’s because you made the above configuration. As for why it is stuck there, it may be because there are too many places that need to be replaced. Maybe you can just wait patiently for a while. By the way, if you will true改为false, you will let git handle it by itself, so no warning will be reported. This does not fundamentally solve the problem. Doing so may cause the line breaks between you and your friends to be inconsistent.

Of course, there is a better way to solve the problem of inconsistent line breaks - using .gitattributes文件统一换行符。这个文件有点儿类似于.gitignore, not only the names are similar, but the usage and writing syntax are also similar.

This file must be located in the root directory of the warehouse and can be modified and submitted like other files. Here’s how to write this file:

The file content looks like a table, divided into two columns: the left column is the file name that git needs to match; the right column is the newline format that git needs to use. Let’s take a look at a chestnut:

# Set the default behavior, in case people don't have core.autocrlf set.
* text=auto

# Explicitly declare text files you want to always be normalized and converted
# to native line endings on checkout.
*.c text
*.h text

# Declare files that will always have CRLF line endings on checkout.
*.sln text eol=crlf

# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary

If you are familiar with .gitignore的话，你会觉得上面这个文件的左边一列很熟悉，这里我们就不再赘述了，不熟悉的话，请自行查阅相关资料。唯一的不同就是.gitattributes文件多了右边一列，如text, text eol=crlf, binary, we just said that this column is used to set the newline format used by the corresponding file on the left. The left and right columns are separated by spaces. Let’s introduce the syntax of the right column in detail:

• text=auto
  Let git handle what newline format the matching file on the left uses. This is the default option.

• text eol=crlf
  Uniformly use CRLF newline format for the matching files on the left. If LF appears in any file, it will be converted to CRLF.

• text eol=lf
  Uniformly use LF newline format for the matching files on the left. If CRLF appears in any file, it will be converted to LF.

• binarybinary
  告诉git这不是文本文件，不应该对其中的换行符进行改变。另外，binary和符号-text -diff tells git that this is not a text file and the newlines in it should not be changed. In addition, binary and the symbol -text -diff are equivalent.

The above syntax should be enough. If you are interested, you can check the relevant information by yourself, such as the official information: https://git-scm.com/book/en/v...

Generally speaking, the second method is the best solution, although it is more troublesome than the first method.

P.S: Organized into a blog: Git handles line break problem

You did it the other way around, it should be set to true.