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

Editor to share with you how to solve the problem of newline characters in git multi-system cooperation, I believe most people do not know much about it, so share this article for your reference. I hope you will gain a lot after reading this article. Let's learn about it together.

Formatting and Blank

Formatting and whitespace are minor headaches that many developers encounter when collaborating, especially in cross-platform situations. Due to different editors or Windows programmers adding a carriage return newline at the end of the file line in a cross-platform project, some minor space changes will inadvertently enter the collaborative work or submitted patches. Don't worry, some of Git's configuration options will help you solve these problems.

Core.autocrlf

If you are writing programs on Windows, or if you are working with others who are programming on Windows and you are on other systems, you may encounter end-of-line Terminator problems. This is because Windows uses carriage return and newline characters to end a line, while Mac and Linux use only one character newline. Although this is a small problem, it can greatly disrupt cross-platform collaboration.

Git can automatically convert the line Terminator CRLF to LF when you submit, and LF to CRLF when you check out code. Use core.autocrlf to turn on this feature, and if you are on a Windows system, set it to true so that when the code is checked out, LF is converted to CRLF:

$git config-global core.autocrlf true

Linux or Mac systems use LF as the line Terminator, so you don't want Git to convert automatically when checking out a file; when a file with CRLF as a line Terminator is accidentally introduced, you must want to fix it and set core.autocrlf to input to tell Git to convert CRLF to LF on submission, but not on check out:

$git config-global core.autocrlf input

This preserves CRLF in the check-out file on Windows systems, and LF on Mac and Linux systems, including repositories.

If you are a Windows programmer and are working on a project that runs only on Windows, you can set false to disable this feature and record the carriage return in the library:

$git config-global core.autocrlf falsecore.whitespace

Git presets some options to detect and correct blank problems. Two of its four main options are turned on by default, the other two are turned off, and you are free to turn them on or off.

The two options that are turned on by default are trailing-space and space-before-tab,trailing-space to find the space at the end of each line, and space-before-tab to look for the space before the tab at the beginning of each line.

The two options that are turned off by default are that indent-with-non-tab and cr-at-eol,indent-with-non-tab look for lines that begin with more than eight spaces (not tabs), and cr-at-eol lets Git know that the trailing carriage return is legal.

Set core.whitespace, turn the options on or off as you want, and separate the options with commas. Turn it off by removing the option from the comma-separated chain or by adding-before the option, for example, if you want to turn on all options except cr-at-eol:

$git config-global core.whitespace\ trailing-space,space-before-tab,indent-with-non-tab

Git detects these problems when you run the git diff command and shades the output, so you may be able to fix them before submitting, and you will also benefit from patching with git apply. If the patch you are about to use has a special blank problem, you can ask Git to issue a warning:

$git apply-whitespace=warn

Or have Git automatically fix the problem before patching it:

$git apply-whitespace=fix

These options can also be applied to derivatives. If files with blank problems are submitted but haven't been pushed to the upper stream, you can run rebase with the-whitespace=fix option to have Git fix them automatically when rewriting the patch.

Server-side configuration

There are not many Git server-side configuration options, but there are still some interesting options worth seeing.

Receive.fsckObjects

By default, Git does not check the consistency of all objects during push. Although it confirms the validity of each object and whether it still matches the SHA-1 checksum, Git does not check for consistency each time it is pushed. For Git, the larger the library or pushed file, the higher the cost of this operation, and each push will take more time. If you want Git to check consistency during each push, set receive.fsckObjects to true to force it to do so:

$git config-system receive.fsckObjects true

Git now checks the integrity of the library before each push takes effect to ensure that problematic clients do not introduce destructive data.

Receive.denyNonFastForwards

If you derive the submission history that has been pushed, and then push, or otherwise push a submission history to the remote branch, and the submission history is not in the remote branch, such a push will be rejected. This is usually a good forbidden strategy, but sometimes if you are doing a derivation and are sure to update the remote branch, you can force the update by adding the-f flag after the push command.

To disable this forced update feature, you can set receive.denyNonFastForwards:

$git config-system receive.denyNonFastForwards true

As you will see later, the same can be achieved with server-side receive hooks. This method allows for more detailed control, such as disabling specific users from making mandatory updates.

Receive.denyDeletes

One way to circumvent the denyNonFastForwards policy is for the user to delete the branch and then push back the new reference. In the newer version of Git (starting with version 1.6.1), set receive.denyDeletes to true:

$git config-system receive.denyDeletes true

This prevents branches and tags from being deleted during the push process-no user can do so. To delete a remote branch, you must manually delete the reference file from the server. This can also be done through user access control lists

These are all the contents of the article "how to solve the problem of newline characters in git multi-system cooperation". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.