Configuring Git to handle line endings

To avoid problems in your diffs, you can configure Git to properly handle line endings.

In this article

Every time you press return on your keyboard you insert an invisible character called a line ending. Different operating systems handle line endings differently.

When you’re collaborating on projects with Git and GitHub, Git might produce unexpected results if, for example, you’re working on a Windows machine, and your collaborator has made a change in OS X.

You can configure Git to handle line endings automatically so you can collaborate effectively with people who use different operating systems.

Global settings for line endings

The git config core.autocrlf command is used to change how Git handles line endings. It takes a single argument.

On OS X, you simply pass input to the configuration. For example:

On Windows, you simply pass true to the configuration. For example:

On Linux, you simply pass input to the configuration. For example:

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:

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.
2. Add all your changed files back and normalize the line endings.
3. Show the rewritten, normalized files.
4. Commit the changes to your repository.

How can I use `LF` line endings in Git for Windows in 2020 for good?

Our repository uses LF , my Git for Windows installation uses Checkout as-is, commit Unix-style line endings,

but I still end up with wall of errors in every file I checkout in my IDE as it still receives CRLF all the time even though it does support LF and is configured to use LF via checked in .editorconfig file (or in its own settings).:

It is 2020 already and IDEs and tooling already support LF on Windows, so how can I have the nice things too?

2 Answers 2

The way to go is to use a .gitattributes with the good instruction to give to git.

For your case, it should be: * text=auto eol=lf

.editorconfig is only for saving files for editors supporting it.

But after that, you will have to normalize the files:

git add —renormalize .

There are two git config attributes that affect the line endings: core.autocrlf and core.eol .
Previously, you were told to use core.autocrlf = true to be able to work on cross-platform projects, but it’s not true any more.

If your system/IDE/tooling support LF and you do want to use LF as everyone else in your team without any silent lf->crlf->lf normalizations, you must turn off autocrlf and configure eol to not infer native line endings, but force it to use lf .

Now there are two ways to achieve LF in all your files a/o repos:

1. Globally for all repositories on your local machine.
2. Per-repository via checked-in .gitattributes file.
   This file overrides any local configuration for everyone who clones the repo.

I personally recommend to go with both for all local repos and to ensure cross-platform cross-dev consistency.

1) Globally for all repositories on your local machine

Being in your working directory (your local repo):

First commit everything

Let’s be paranoid a bit and set it both globally and in repo as well. Just in case.

Delete everything «code» except .git .
You can also omit dependencies, installed files (such as node_modules ), build files and any git-ignored file as well.

Things should be working now. Newly checked files should follow the new configuration and keep whatever line-endings were cloned from the remote repo.

Note that if your remote repo uses mix of crlf lf endings, you will also have to run and push

2) Per-repository via checked-in .gitattributes file

Being in your working directory (your local repo):

Create .gitattributes file in the root with this content:

Commit the file (and everything else)

IMPORTANT NOTE: After you introduce the file into the repository, it is necessary that everyone who still has old CRLF files does step 3 and 4 to update their working directory as just checking out the commit doesn’t affect already existing files.

Notes

setting core.autocrlf to true or input overrides core.eol

Troubleshooting

Reinstall git for windows with third option (as in the screenshot in Q)

Configuring Git to handle line endings

To avoid problems in your diffs, you can configure Git to properly handle line endings.

In this article

Every time you press return on your keyboard you insert an invisible character called a line ending. Different operating systems handle line endings differently.

When you’re collaborating on projects with Git and GitHub Enterprise Server, Git might produce unexpected results if, for example, you’re working on a Windows machine, and your collaborator has made a change in OS X.

You can configure Git to handle line endings automatically so you can collaborate effectively with people who use different operating systems.

Global settings for line endings

The git config core.autocrlf command is used to change how Git handles line endings. It takes a single argument.

On OS X, you simply pass input to the configuration. For example:

On Windows, you simply pass true to the configuration. For example:

On Linux, you simply pass input to the configuration. For example:

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:

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.
2. Add all your changed files back and normalize the line endings.
3. Show the rewritten, normalized files.
4. Commit the changes to your repository.

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»)

5 Answers 5

The normal way to control this is with git config

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:

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

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. Use .gitattributes file

Global Configuration

This will fix any CRLF to LF when you commit.

This will make sure when you checkout in windows, all LF will convert 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 set their config. This file should keep in repo’s root path and if exist one, git will respect it.

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 wanted to tell explicitly, then use

First one is for checkout and second one is for commit.

Treat all .jpg images as binary files, regardless of path. So no conversion needed.

Or you can add path qualifiers:

For a repository setting solution, that can be redistributed to all developers, check out the text attribute in the .gitattributes file. This way, developers dont have to manually set their own line endings on the repository, and because different repositories can have different line ending styles, global core.autocrlf is not the best, at least in my opinion.

For example unsetting this attribute on a given path [. — text] will force git not to touch line endings when checking in and checking out. In my opinion, this is the best behavior, as most modern text editors can handle both type of line endings. Also, if you as a developer still want to do line ending conversion when checking in, you can still set the path to match certain files or set the eol attribute (in .gitattributes) on your repository.

Also check out this related post, which describes .gitattributes file and text attribute in more detail: What’s the best CRLF (carriage return, line feed) handling strategy with Git?

For me what did the trick was running the command

inside the folder of the project, I wanted it specifically for one project.

That command changed the file in path /.git/config (fyi .git is a hidden folder) by adding the lines

at the end of the file. I suppose changing the file does the same trick as well.

Git status ignore line endings / identical files / windows & linux environment / dropbox / mled

ignore line ending differences?

I use randomly Windows and Linux to work on the project. The project is in Dropbox.

I found a lot about how do make git diff ignore line endings. Since i use meld git diff opens meld for each file. And meld says «identical file».

So how do I avoid this. Git should only open meld for changed files. And git status should not report files as changed if only the file ending is different.

EDIT: Cause:

This happened because of this setting on Windows

So I checked out the working copy on Linux and set core.autocrlf false on Windows.

It would be still nice to know how to make git status ignore different new lines.

6 Answers 6

Try setting core.autocrlf value like this :

This answer seems relevant since the OP makes reference to a need for a multi-OS solution. This Github help article details available approaches for handling lines endings cross-OS. There are global and per-repo approaches to managing cross-os line endings.

Global approach

Configure Git line endings handling on Linux or OS X:

Configure Git line endings handling on Windows:

Per-repo approach:

In the root of your repo, create a .gitattributes file and define line ending settings for your project files, one line at a time in the following format: path_regex line-ending-settings where line-ending-settings is one of the following:

• text
• binary (files that Git should not modify line endings for — as this can cause some image types such as PNGs not to render in a browser)

The text value can be configured further to instruct Git on how to handle line endings for matching files:

• text — Changes line endings to OS native line endings.
• text eol=crlf — Converts line endings to CRLF on checkout.
• text eol=lf — Converts line endings to LF on checkout.
• text=auto — Sensible default that leaves line handle up to Git’s discretion.

Here is the content of a sample .gitattributes file:

More on how to refresh your repo after changing line endings settings here. Tldr:

backup your files with Git, delete every file in your repository (except the .git directory), and then restore the files all at once. Save your current files in Git, so that none of your work is lost.

git commit -m «Saving files before refreshing line endings»

Remove the index and force Git to rescan the working directory.

Rewrite the Git index to pick up all the new line endings.

Show the rewritten, normalized files.

In some cases, this is all that needs to be done. Others may need to complete the following additional steps:

Add all your changed files back, and prepare them for a commit. This is your chance to inspect which files, if any, were unchanged.

It is perfectly safe to see a lot of messages here that read[s] «warning: CRLF will be replaced by LF in file.»

Commit the changes to your repository.

git commit -m «Normalize all the line endings»