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")
The only specific reasons to set
git statusshowing all your files as
modifiedbecause 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
git config --global core.autocrlf false).
Note that this config would be a local one (because config isn't pushed from repo to repo)
*.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"
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 the
core.autocrlfsetting, allowing you to ensure consistent behaviour for all users regardless of their git settings.
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
# 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? :-/