How to change line-ending settings int git?

How to change line-ending settings

Is there a file or menu that will let me change the settings on how to deal with line endings?

I read there are 3 options:

  1. Checkout Windows-style, commit Unix-style

    Git will convert LF to CRLF when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects, this is the recommended setting on Windows ("core.autocrlf" is set to "true")

  2. Checkout as-is, commit Unix-style

    Git will not perform any conversion when checking out text files. When committing text files, CRLF will be converted to LF. For cross-platform projects this is the recommended setting on Unix ("core.autocrlf" is set to "input").

  3. Checkout as-is, commit as-is

    Git will not perform any conversions when checking out or committing text files. Choosing this option is not recommended for cross-platform projects ("core.autocrlf" is set to "false")

 

I actually find that the 3-rd option works better. Otherwise I often have been in situations when I edit both batch and sh scripts on the same platform (Windows/Linux) and then commit them and Git automatically "fixes" line endings for one platform... No, I prefer to be self-conscious about line endings and commit/checkout them exactly as they are. Aug 6 '18 at 8:11
 
回答1

The normal way to control this is with git config

For example

git config --global core.autocrlf true

For details, scroll down in this link to Pro Git to the section named "core.autocrlf"


If you want to know what file this is saved in, you can run the command:

git config --global --edit

and the git global config file should open in a text editor, and you can see where that file was loaded from.

 

回答2

Line ending format used in OS:

  • Windows: CR (Carriage Return \r) and LF (LineFeed \n) pair
  • OSX, Linux: LF (LineFeed \n)

We can configure git to auto-correct line ending formats for each OS in two ways.

  1. Git Global configuration
  2. Using .gitattributes file

Global Configuration

In Linux/OSX

git config --global core.autocrlf input

This will fix any CRLF to LF when you commit.

In Windows

git config --global core.autocrlf true

This will make sure that, when you checkout in windows, all LF will be converted to CRLF.

.gitattributes File

It is a good idea to keep a .gitattributes file as we don't want to expect everyone in our team to set their own config. This file should be palced in the repository root and. If it exists, git will respect it.

* text=auto

This will treat all files as text files and convert to OS's line ending on checkout and back to LF on commit automatically. If you want to specify the line ending explicitly, you can use:

* text eol=crlf
* text eol=lf

The first one is for checkout and the second one is for commit.

*.jpg binary

This will treat all .jpg images as binary files, regardless of path. So no conversion needed.

Or you can add path qualifiers:

my_path/**/*.jpg binary
 

 

Why should I use core.autocrlf=true in Git?

回答1

The only specific reasons to set autocrlf to true are:

  • avoid git status showing all your files as modified because of the automatic EOL conversion done when cloning a Unix-based EOL Git repo to a Windows one (see issue 83 for instance)
  • and your coding tools somehow depends on a native EOL style being present in your file:

Unless you can see specific treatment which must deal with native EOL, you are better off leaving autocrlf to false (git config --global core.autocrlf false).

Note that this config would be a local one (because config isn't pushed from repo to repo)

If you want the same config for all users cloning that repo, check out "What's the best CRLF handling strategy with git?", using the text attribute in the .gitattributes file.

Example:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Note: starting git 2.8 (March 2016), merge markers will no longer introduce mixed line ending (LF) in a CRLF file.
See "Make Git use CRLF on its “<<<<<<< HEAD” merge lines"

 

评论1:

@VonC: I don't think this answer is correct. Using core.autocrlf=true on Windows works as expected. All files from the repo (which should have LF line endings in this scenario) are converted to CRLF line endings on checkout to a Windows PC. All files are converted back to LF line endings on commit from a Windows PC. The way to get in trouble is to checkout initially to a Windows PC with the wrong core.autocrlf setting (which is entirely too easy to do). Jul 9 '10 at 11:30
 
 
评论2
I would definitely use false, I've never been a big fan of automatic or magic things happening in the background. Just use \n and UTF-8 everywhere and you will be fine. If some nut-head does not understand that there are conventions and rules and forgets to use UTF-8 or \n, then someone converts them manually and slaps his face.
– Tower
Jun 11 '12 at 16:01
 
 
回答2

I am a .NET developer and have used Git and Visual Studio for years. My strong recommendation is to set line endings to true. And do it as early as you can in the lifetime of your Repository.

That being said, I HATE that Git changes my line endings. Source control should only save and retrieve the work I do, it should NOT modify it. Ever. But it does.

What will happen if you don't have every developer set to true, is ONE developer eventually will set to true. This will begin to change the line endings of all of your files to LF in your repo. And when users set to false check those out, Visual Studio will warn you, and ask you to change them. You will have 2 things happen very quickly. One, you will get more and more of those warnings, the bigger your team the more you get. The second, and worse thing, is that it will show that every line of every modified file was changed(because the line endings of every line will be changed by the true guy). Eventually, you won't be able to track changes in your repo reliably anymore. It is MUCH easier and cleaner to make everyone keep to true than to try to keep everyone false. As horrible as it is to live with the fact that your trusted source control is doing something it should not. Ever.

 

 

Configuring Git to handle line endings

Per-repository settings

Optionally, you can configure a .gitattributes file to manage how Git reads line endings in a specific repository. When you commit this file to a repository, it overrides the core.autocrlf setting for all repository contributors. This ensures consistent behavior for all users, regardless of their Git settings and environment.

The .gitattributes file must be created in the root of the repository and committed like any other file.

A .gitattributes file looks like a table with two columns:

  • On the left is the file name for Git to match.
  • On the right is the line ending configuration that Git should use for those files.

Example

Here's an example .gitattributes file. You can use it as a template for your repositories:

# 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

You'll notice that files are matched—*.c, *.sln, *.png—, separated by a space, then given a setting—text, text eol=crlf, binary. We'll go over some possible settings below.

  • text=auto Git will handle the files in whatever way it thinks is best. This is a good default option.

  • text eol=crlf Git will always convert line endings to CRLF on checkout. You should use this for files that must keep CRLF endings, even on OSX or Linux.

  • text eol=lf Git will always convert line endings to LF on checkout. You should use this for files that must keep LF endings, even on Windows.

  • binary Git will understand that the files specified are not text, and it should not try to change them. The binary setting is also an alias for -text -diff.

 

Refreshing a repository after changing line endings

When you set the core.autocrlf option or commit a .gitattributes file, you may find that Git reports changes to files that you have not modified. Git has changed line endings to match your new configuration.

To ensure that all the line endings in your repository match your new configuration, backup your files with Git, delete all files in your repository (except the .git directory), then restore the files all at once.

  1. Save your current files in Git, so that none of your work is lost.
    $ git add . -u
    $ git commit -m "Saving files before refreshing line endings"
  2. Add all your changed files back and normalize the line endings.
    $ git add --renormalize .
  3. Show the rewritten, normalized files.
    $ git status
  4. Commit the changes to your repository.
    $ git commit -m "Normalize all the line endings"
 

What's the best CRLF (carriage return, line feed) handling strategy with Git?

Almost four years after asking this question, I have finally found an answer that completely satisfies me!

See the details in github:help's guide to Dealing with line endings.

Git allows you to set the line ending properties for a repo directly using the text attribute in the .gitattributes file. This file is committed into the repo and overrides the core.autocrlf setting, allowing you to ensure consistent behaviour for all users regardless of their git settings.

And thus

The advantage of this is that your end of line configuration now travels with your repository and you don't need to worry about whether or not collaborators have the proper global settings.

Here's an example of a .gitattributes file

# Auto detect text files and perform LF normalization
*        text=auto

*.cs     text diff=csharp
*.java   text diff=java
*.html   text diff=html
*.css    text
*.js     text
*.sql    text

*.csproj text merge=union
*.sln    text merge=union eol=crlf

*.docx   diff=astextplain
*.DOCX   diff=astextplain

# absolute paths are ok, as are globs
/**/postinst* text eol=lf

# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf

There is a convenient collection of ready to use .gitattributes files for the most popular programming languages. It's useful to get you started.

Once you've created or adjusted your .gitattributes, you should perform a once-and-for-all line endings re-normalization.

Note that the GitHub Desktop app can suggest and create a .gitattributes file after you open your project's Git repo in the app. To try that, click the gear icon (in the upper right corner) > Repository settings ... > Line endings and attributes. You will be asked to add the recommended .gitattributes and if you agree, the app will also perform a normalization of all the files in your repository.

Finally, the Mind the End of Your Line article provides more background and explains how Git has evolved on the matters at hand. I consider this required reading.

You've probably got users in your team who use EGit or JGit (tools like Eclipse and TeamCity use them) to commit their changes. Then you're out of luck, as @gatinueta explained in this answer's comments:

This setting will not satisfy you completely if you have people working with Egit or JGit in your team, since those tools will just ignore .gitattributes and happily check in CRLF files https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372

One trick might be to have them commit their changes in another client, say SourceTree. Our team back then preferred that tool to Eclipse's EGit for many use cases.

Who said software is easy? :-/

 

评论:

For Windows I'm usually inclined to set the global core.autocrlf = false - I prefer LF everywhere, but some of the Windows tools like Visual Studio insist on CRLF endings in certain files (and even mix them in a few..) ; not munging line endings is the safest option. If you know what you are doing, I'd probably use core.autocrlf = input and make exceptions for projects on Windows that you know are sensitive to line endings. As others point out, every decent text editor supports LF endings now. I actually think core.autocrlf = true can probably cause more trouble than it prevents.
– Adrian
May 7 '14 at 7:57
 
 
回答2
Don't convert line endings. It's not the VCS's job to interpret data -- just store and version it. Every modern text editor can read both kinds of line endings anyway.
 
 
评论:
Seconded. If you have problems with inconsistent line-endings, the best solution is shout at whoever's using the wrong editor settings until they fix it.
– Mike F
Oct 4 '08 at 20:59
 
 
Disagree. Native linefeeds on all platforms is a convenience. Feb 27 '10 at 10:04

 

Git has an option not to convert line-endings it is autocrlf=false and unless you are doing cross-platform development, like say Mono it is best left to false when running under Windows and set to true if you will be developing open-source for Mono. Feb 10 '11 at 20:09
 

 

 

 

posted @ 2021-09-18 19:33  ChuckLu  阅读(7)  评论(0编辑  收藏  举报