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:
-
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")
-
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").
-
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")
Why should I use core.autocrlf=true in Git?
回答1
The only specific reasons to set autocrlf to true are:
- avoid
git statusshowing all your files asmodifiedbecause 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:
- for instance, a code generator hard-coded to detect native EOL
- other external batches (external to your repo) with regexp or code set to detect native EOL
- I believe some Eclipse plugins can produce files with CRLF regardless on platform, which can be a problem.
- You code with Notepad.exe (unless you are using a Windows 10 2018.09+, where Notepad respects the EOL character detected).
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：
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.
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=autoGit will handle the files in whatever way it thinks is best. This is a good default option. -
text eol=crlfGit will always convert line endings toCRLFon checkout. You should use this for files that must keepCRLFendings, even on OSX or Linux. -
text eol=lfGit will always convert line endings toLFon checkout. You should use this for files that must keep LF endings, even on Windows. -
binaryGit will understand that the files specified are not text, and it should not try to change them. Thebinarysetting 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.
- 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" - Add all your changed files back and normalize the line endings.
$ git add --renormalize . - Show the rewritten, normalized files.
$ git status - 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
.gitattributesfile. This file is committed into the repo and overrides thecore.autocrlfsetting, 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? :-/
评论：
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.
作者:Chuck Lu GitHub |
The normal way to control this is with
git configFor example
git config --global core.autocrlf trueFor 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:
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:
CR(Carriage Return\r) andLF(LineFeed\n) pairLF(LineFeed\n)We can configure git to auto-correct line ending formats for each OS in two ways.
.gitattributesfileGlobal Configuration
In Linux/OSX
git config --global core.autocrlf inputThis will fix any
CRLFtoLFwhen you commit.In Windows
git config --global core.autocrlf trueThis will make sure that, when you checkout in windows, all
LFwill be converted toCRLF..gitattributes File
It is a good idea to keep a
.gitattributesfile 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=autoThis will treat all files as text files and convert to OS's line ending on checkout and back to
LFon commit automatically. If you want to specify the line ending explicitly, you can use:* text eol=crlf * text eol=lfThe first one is for checkout and the second one is for commit.
*.jpg binaryThis will treat all
.jpgimages as binary files, regardless of path. So no conversion needed.Or you can add path qualifiers:
my_path/**/*.jpg binary