Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What is the operation related to the GIT newline character

2025-03-29 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/02 Report--

This article will explain in detail what is the operation related to GIT newline characters, and the content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

Background

On the origin and difference of the two concepts of "carriage return" and "line feed". Before the advent of computers, there was a thing called teletypewriter (Teletype Model 33) that could type 10 characters per second. But it has a problem, that is, it takes 0.2 seconds to type a newline, which is exactly two characters. If a new character is passed in these 0.2 seconds, then the character will be lost.

So the developers came up with a solution to this problem by adding two characters after each line to indicate the end. One is called "enter", which tells the typewriter to position the printhead at the left boundary; the other is called "line break", which tells the typewriter to move the paper down one line.

Later, the computer was invented, and these two concepts were applied to the computer. At that time, memory was so expensive that some scientists thought it was too wasteful to add two characters to the end of each line. As a result, differences emerged. In the Unix system, there is only "" or "\ n" at the end of each line; in the Windows system, the end of each line is "", that is, "\ r\ n"; in the Mac system, each line ends with "". One direct consequence is that if files under Unix/Mac are opened in Windows, all text will become one line, while files in Windows will have an extra ^ M symbol at the end of each line if they are opened under Unix/Mac.

The files created by Windows are\ n\ r terminated, while Unix operating systems such as Linux are\ nterminated. So the text of Unix will be lost to Windows (software such as ultraedit can correctly recognize it), and the symbol of ^ M will appear in turn.

The text newline characters used in operating systems such as Windows are different from those used in Unix/Linux operating systems. The newline characters entered in Windows systems will not be displayed as "newline" under Unix/Linux, but as the symbol ^ M (this is a special mark specified by Linux and other systems, accounting for a character size, not a combination of ^ and M, and cannot be printed). Many text editors under Linux (command line) will add their own newline character after displaying this tag to avoid confusion (only for display, supplementary newline characters will not be written to the file, there is a special command to replace Windows newline characters with Linux newline characters). Newline characters in Unix/Linux systems will be ignored in Windows text editors and the whole text will be messed up.

Automatic conversion of Git newline characters

Git's "newline automatic conversion" function sounds smart and sweet because it tries to maintain the consistency of files in the repository (UNIX style) and the compatibility of local files (Windows style). Unfortunately, this feature is available with bug and is unlikely to be fixed any time soon.

The problem is that if the file you have is a UTF-8 file that contains Chinese characters, then the "newline automatic conversion" feature does not work when submitted (but there is no problem with conversion processing when checked out). I guess maybe this function module crashed and returned when dealing with the combination of Chinese characters + CRLF.

Example: you check out a file in the default state of Git under Windows, write a line of comments in Chinese (or the file already contains Chinese), and then save and submit. Inadvertently, your files were destroyed. Because the file you submitted to the repository has completely changed into Windows style (the UNIX style was converted to Windows style when checked out but not changed when submitted), there are changes on every line (see the schematic diagram at the beginning of this article), and this change is not visible (most diff tools are difficult to show the newline character clearly), which ultimately makes it impossible for anyone to see what you have changed in this submission. It's not over. If other buddies find out about this problem and kindly change the newline character back, and then you repeat the above tragedy, then the editing history of this file is basically a mystery. Because it is almost impossible for foreigners to step on this hole, the bug has been hidden all the time.

Git newline character configuration recommendation

Multi-platform, multi-IDE, team collaboration and cross-platform development are the problems that most projects will face, so take precautions and unify the newline characters at the beginning of the project (technical management in the project is an art! ).

The team needs to establish a uniform newline standard (UNIX style is recommended, because Git uses UNIX newline characters)

Preparatory work: configure the code editor and IDE to meet two criteria:

The team's uniform newline standard is used by default when creating a new file.

Leave the existing newline format unchanged when opening the file (do not do automatic conversion)

Turn off automatic conversion of Git newline characters

When off, Git will not tamper with your newline character, and you can completely and predictably control your newline style.

The following is mainly for different Git clients, the operation methods are introduced respectively.

Git for Windows

Officially produced by Git, the "newline automatic conversion" feature will be touted to you during installation, and it is estimated that most people will not hesitate to choose the first item (automatic conversion) after reading the gorgeous introduction of features. Please resist the temptation and choose the last one (do not do anything).

If you have made the wrong choice and do not need to reinstall, you can use the command line to modify the settings. Very simple, directly open the command line tool Git Bash that comes with the goods, enter the following command, and then hit enter: git config-- global core.autocrlf false

TortoiseGit

TortoiseGit, as the main client, is actually a GUI shell based on Git for Windows, and the settings you make in Git for Windows will affect the configuration of TortoiseGit.

If Git for Windows is not installed, right-click in the Windows Explorer window and select "TortoiseGit → Settings → Git" to set it.

Windows client of GitHub

GitHub's Windows client is actually a shell that comes with a portable version of Git for Windows. This portable version and your own installation of Git for Windows are independent of each other, but they both use the same configuration file (actually the .gitconfig file in the current user's home directory).

So if you've already configured your own installation of Git for Windows, don't worry about it. But if you only have GitHub's Windows client installed on your machine, the easiest way to configure it is to modify the configuration file manually.

Modify the global configuration file for Git

Go to the current user's home directory and modify the .gitconfig file

Find autocrlf in the [core] section and change its value to false. If you can't find it, add a new line in the [core] section: autocrlf = false

In fact, the final effect of all the command line or graphical interface configuration methods described above is the same, because they are essentially modifying the configuration file.

Turn off the automatic conversion of newline characters, worried that the file into the Windows carriage return newline character, Git to prevent this kind of your mistake, provides a newline character check function (core.safecrlf), you can submit to check whether the document mixed with different styles of newline characters. The options for this feature are as follows:

False-No tests are performed

Warn-check and warn on submission

True-check at the time of submission and refuse to submit if mixed use is found

I recommend using the strictest true option.

Like core.autocrlf, you can modify this option through the command line, graphical interface, and configuration files. There is no need to elaborate on the specific operation, let's cite some examples.

Line feeds in Eclipse configure the display format of the switch newline characters

Change to a newline character in Unix style

Eclipse comes with the Git tool to turn off the automatic conversion of newline characters

About the GIT newline character related operation is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report