background
On the history and differences between carriage Return and line feed. Before computers, there was something called a Teletype Model 33 that could type 10 characters per second. One problem is that it takes 0.2 seconds to type a newline, which is exactly two characters. If a new character is passed within 0.2 seconds, the character will be lost.
So the developers figured out a way to solve this problem by adding two ending characters to each line. One, called a carriage return, tells the typewriter to position the print head on the left edge. The other, called “line break,” tells the typewriter to move the paper down one line.
Later, computers were invented, and these two concepts were applied to computers. Back then, memory was expensive, and some scientists thought it was wasteful to add two characters to the end of each line; just one would do. So, there was a disagreement. On Unix, each line ends with “< line wrap >”, or “\n”; On Windows, each line ends with “< enter >< newline >”, i.e. “\r\n”; On the Mac, each line ends with “< enter >”. As a direct result, a file on Unix/Mac opens on Windows and all the text becomes a single line. Windows files opened on Unix/Mac may have an extra ^M symbol at the end of each line.
Windows creates files that end \n\r, whereas Unix-like operating systems such as Linux do. So Unix text to Windows will appear newline loss (UltraEdit such software can correctly identify); And the opposite is going to be the M sign
The text newline character used by Windows and other operating systems is different from that used by Unix/Linux. On Unix/Linux, a new line character is not displayed as a “newline”. Instead, it is displayed as ^M. Not a combination of ^ and M, it will not print. Many Linux text editors (command lines) will display this flag with a new line break of their own to avoid clutter (just for display, the supplementary line break is not written to the file, there are special commands to replace Windows line breaks with Linux line breaks). Newlines on Unix/Linux will be ignored in a Windows text editor, and the text will be jumbled.
Git newlines are automatically converted
Git’s “automatic newline conversion” may sound smart and sweet, as it tries to keep files consistent in the repository (Unix-style) while keeping files compatible locally (Windows-style). Unfortunately, this feature is buggy and unlikely to be fixed anytime soon.
The problem is that if you have a UTF-8 file that contains Chinese characters, the “automatic conversion of newlines” will not work on submission (but on checkout). I guess the function module crashed when handling the Chinese character + CRLF combination.
Example: on Windows, you check out a file with Git in its default state, write a line of Chinese comments (or the file contains Chinese anyway), and save it to commit… Your files are destroyed before you know it. Because the file you submitted to the repository is completely Windows-style (check out from UNIX to Windows but not commit), with every line changed (see the schematic at the beginning of this article), This change is not visible (most diff tools have a hard time showing line breaks), which ultimately makes it impossible to see what you’ve changed this time. And that’s not all. If someone else notices the problem and kindly changes the newline back, and you repeat the same thing again, the editing history of the file is basically a mystery. Since it is almost impossible for foreigners to step on it, the bug has always existed in secrecy.
Git newline configuration suggestions
Multiple platforms, multiple ides, team collaboration, and cross-platform development are some of the problems most projects will face, so be prepared for them by unifying line breaks at the beginning of the project (technical management is an art!). .
The team needs to decide on a unified standard for newlines (Unix-style is recommended because Git uses UNIX newlines)
Preparation: Configure the code editor and IDE to meet two standards:
- The team’s standard newline character is used by default when creating new files
- Leave the existing newline format unchanged when opening the file (don’t do automatic conversion)
Turn off Git newline automatic conversion
When you turn it off, Git doesn’t do anything to your newlines, and you have complete and predictable control over your newline style.
The following describes how to do this for different Git clients.
Git for Windows
Git will sell you the “automatic newline conversion” feature when you install it, and most people won’t hesitate to choose the first option (automatic conversion) after reading the beautiful feature description. Resist the temptation to choose the last option.
If you’ve made the wrong choice, you don’t need to reinstall, you can just use the command line to change the Settings. Git config –global core. Autocrat lf false
TortoiseGit
Git for Windows is a GUI shell for All Settings in The TortoiseGit repository.
If you do not have Git for Windows installed, right-click On the Windows Explorer window and choose TortoiseGit → Settings → Git from the shortcut menu.
GitHub Windows client
GitHub’s Windows client is actually a shell that comes with a portable version of Git for Windows. This portable version is separate from your own Git for Windows installation, but they both use the same configuration file (essentially the.gitconfig file in the current user’s home directory).
So if you’ve already configured your own Git for Windows installation, don’t worry. But if you’ve only ever installed GitHub’s Windows client on your machine, the easiest way to configure it is to manually modify the configuration file.
Modify Git global configuration files
Go to the current user’s home directory and modify the.gitconfig file
Change the value of the cyclic amp (autocrat) LF to false in the [core] section. Autocrat lf = false if no change is found in the [core] section
In fact, the end result of all the command-line or graphical configuration methods described above is the same, because you are essentially modifying the configuration file.
Safecrlf (core. Safecrlf) is available to check whether the file has mixed different styles of newlines at commit time. The options for this feature are as follows:
false– No testswarn– Check and warn when submittingtrue– Check at commit time and reject commit if found to be mixed
I recommend using the strictest true option.
By using the same method as Core. Autocrlf, you can change this option by using the command line, a graphical interface, and a configuration file. Specific operation is not repeated, we draw inferences by themselves.
Newline configuration for Eclipse
Toggles the display format of a newline character
Change to a UNIx-style line break
Eclipse’s built-in Git tool turns off automatic newline conversion
