681

I want to force Git to check out files under Windows using just LF not CR+LF.
I checked the two configuration options, but was not able to find the right combination of settings.

I want to convert all files to have LF line breaks and keep the LF in the files.

Remark: I used autocrlf = input but this just repairs the files when you commit them.
I want to force it to get them using LF.

Probably I wasn't so clear: the repository is already using LF but the files checked out using Git for Windows are using CR+LF and I want to force Git to get them with LF: forcing Unix line endings.

$ git config --list | grep crlf core.autocrlf=input
Improve this question
12
  • 4
    autocrlf=input is the correct option. Of course it doesn't protect you from files that genuinely have cr+lf in the repository or creating files with cr+lf in another tool before adding them to git. What problems are you having that this doesn't work for? Commented Mar 25, 2010 at 16:10
  • 5
    The files in the repository are already using only LF but when I get them under Windows msysgit converts them to CR+LF. Commented Mar 25, 2010 at 16:19
  • There must be something up with your config; I've just tested this on my msysgit install. With autocrlf set to input, git is leaving lf linefeeds alone. Can you post the output of git config? Commented Mar 25, 2010 at 22:46
  • 1
    In that case, I suggest that you log a bug; preferably pointing to a test repository that exhibits your problem and including steps to reproduce as the behaviour you are seeing is definitely wrong (but I can't reproduce it). Commented Mar 26, 2010 at 11:14
  • 3
    A small tip is to also make sure you are running the git commands on the 'git' you think you are. For example you may have git installed on windows, and git installed on cygwin, so make sure you have set the right git config. Commented Mar 26, 2015 at 10:37

8 Answers 8

Reset to default
849

The proper way to get LF endings in Windows is to first set core.autocrlf to false:

git config --global core.autocrlf false

You need to do this if you are using msysgit, because it sets it to true in its system settings.

Now git won’t do any line ending normalization. If you want files you check in to be normalized, do this: Set text=auto in your .gitattributes for all files:

* text=auto

And set core.eol to lf:

git config --global core.eol lf

Now you can also switch single repos to crlf (in the working directory!) by running

git config core.eol crlf

After you have done the configuration, you might want git to normalize all the files in the repo:

git add --update --renormalize

If you now want git to also normalize the files in your working directory, run these commands:

git ls-files -z | xargs -0 rm git checkout .
Improve this answer
Sign up to request clarification or add additional context in comments.

14 Comments

I'm getting fatal pathspec '' did not match any files, right after git diff --cached --name-only -z | xargs -0 git add
what is the output of git diff --cached --name-only?
It may be worth mentioning that you can set this config while cloning the repo in question, e.g. git clone --config core.autocrlf=false <repo path>.
First I set autocrlf false using command git config --global core.autocrlf false then after git config --global core.eol lf and also for local using command git config core.eol lf. After that, I set hard reset git reset --hard, and its fixed my problem.
What the bottom commands do: first remove all files from git (but actually keep them!) git rm --cached -rf . then show only names of files that changed (the ones you removed) -z: null-terminate | add them (-0: null-terminated) git diff --cached --name-only -z | xargs -0 git add -f <- This makes sure your git history is nice and LF. null-terminated allows for weird things in filenames.
|
475

I come back to this question fairly often, though none of its other answers are quite right for me.
That said, the right answer for me is a mixture of the others.

What I find works is the following:

git config --global core.eol lf git config --global core.autocrlf input

For repos (Git repositories) that were checked out after those global settings were set, everything will be checked out as whatever it is in the repo – hopefully LF (\n).
Any CRLF will be converted to just LF on check-in (commit).

With an existing repo that you have already checked out – that has the correct line endings in the repo but not your working copy – you can run the following commands to fix it:

git rm -rf --cached . git reset --hard HEAD

This will delete (rm) recursively (-r) without prompt (-f), all files except those that you have edited (--cached), from the current directory (.). The reset then returns all those files to a state where they have their true line endings (matching what's in the repo).

If you need to fix the line endings of files in a repo, I recommend grabbing an editor that will let you do that in bulk like IntelliJ or Sublime Text, but I'm sure any good one will likely support this.

Improve this answer

8 Comments

We have a single repo with sub directories that require different line ending handling. So setting a global option does not work for this. Not even in the single repo. How do you apply these same settings in .gitattributes?
Notepad++ also shows the line ending of the currenlty opened file in the bottom right corner. A right click on that field will allow you to change the line endings.
The core.autocrlf input option overrides the core.eol setting, so setting both is redundant. (See git-scm.com/docs/git-config)
Thank you, with your help I have conquered lint and Linux. And can now check in files.
Definitely commit all work before doing any sort of gitfu. This answer is also almost a decade old, and I have no clue if it still works.
|
198

The OP added in his question:

the files checked out using msysgit are using CR+LF and I want to force msysgit to get them with LF

A first simple step would still be in a .gitattributes file:

# 2010 *.txt -crlf # 2020 *.txt text eol=lf

(as noted in the comments by grandchild, referring to .gitattributes End-of-line conversion), to avoid any CRLF conversion for files with correct eol.

And I have always recommended git config --global core.autocrlf false to disable any conversion (which would apply to all versioned files)

See Best practices for cross platform git config?

Since Git 2.16 (Q1 2018), you can use git add --renormalize . to apply those .gitattributes settings immediately.

But a second more powerful step involves a gitattribute filter driver and add a smudge step

filter driver

Whenever you would update your working tree, a script could, only for the files you have specified in the .gitattributes, force the LF eol and any other formatting option you want to enforce.
If the "clear" script doesn't do anything, you will have (after commit) transformed your files, applying exactly the format you need them to follow.

Improve this answer

6 Comments

One question: *.txt refers to all files with .txt extension or to all text files (non binary)? I cannot make a list with all kinds of file extension I will have in the project.
@Sorin: all files with .txt extension. It is preferable to first establish this and test it on a specific group, before generalizing to *, and add a negative rule !*.xyz ... to exclude some few files from that rule.
By now the .gitattributes lines should read: *.txt text eol=lf as per git-scm.com/docs/gitattributes
@grandchild Thank you. I have included your comment in the answer for more visibility.
I guess after we add .gitattributes we have to do git add --renormalize .
|
146

Context

If you

  1. want to force all users to have LF line endings for text files and
  2. you cannot ensure that all users change their git config,

you can do that starting with git 2.10. 2.10 or later is required, because 2.10 fixed the behavior of text=auto together with eol=lf. Source.

Solution

Put a .gitattributes file in the root of your git repository having following contents:

* text=auto eol=lf

Commit it.

Optional tweaks

You can also add an .editorconfig in the root of your repository to ensure that modern tooling creates new files with the desired line endings.

# EditorConfig is awesome: http://EditorConfig.org # top-most EditorConfig file root = true # Unix-style newlines with a newline ending every file [*] end_of_line = lf insert_final_newline = true
Improve this answer

5 Comments

This was the best solution for me. I also combined this with editorconfig.org so that when writing in Intellij I would write out LF EOLs.
This is by far the best solution. No need to manually run any configuration commands!
This single line .gitattributes entry is the best, other solutions can be confusing.
What if I want to be able to retain line endings exactly as in the repository, whatever they are? I'm on Windows, but I use various different repositories, all of which might have their own conventions. I simply want to say "Github, don't mess with the line endings. Leave them exactly as in the repo when I check out, and exactly as in my code when I check in." Then I can tell my editor not to mess with the line endings either, and everyone's happy.
As I read it, setting git config --global core.autocrlf false gets Windows confused; setting git config --global core.autocrlf true means files will always be checked out with CRLF and checked in with LF, and setting * text=auto in .gitattributes seems to make no difference on my setup.
38

core.autocrlf=input is the right setting for what you want, but you might have to do a git update-index --refresh and/or a git reset --hard for the change to take effect.

With core.autocrlf set to input, git will not apply newline-conversion on check-out (so if you have LF in the repo, you'll get LF), but it will make sure that in case you mess up and introduce some CRLFs in the working copy somehow, they won't make their way into the repo.

Improve this answer

1 Comment

The commands should be git rm --cached -r . && git reset --hard
5

The accepted answer is correct

git config --global core.autocrlf false

For anyone coming here just to learn - one very helpful thing to keep in mind is that modern IDEs can render files with LF or CRLF. So imagine you're a lone windows dev on a team of macOS users. You'll be checking out a codebase that's likely ending in LF. The command above ensures that upon checkout, you don't mess up the LF characters.

In your IDE, for example in JetBrains, you should set the project (or globally) to use LF.

1. CTRL + ALT + S for settings 2. Code Style -> General -> Line Separator

enter image description here

Furthermore, in the bottom righthand IDE toolbar, it will display either LF or CRLF, which indicates the setting of the current file. You can click it to change between styles.

enter image description here

So in summary

  1. git config --global core.autocrlf false to avoid changing line endings on checkout.

    • Set this before repo checkout!

  2. IDE setting to avoid changing them on subsequent edits or on new file creation.

Improve this answer

Comments

1

You can find the solution to this problem at: https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings

Simplified description of how you can solve this problem on windows:

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 Windows, you simply pass true to the configuration. For example: C:>git config --global core.autocrlf true

Good luck, I hope I helped.

Improve this answer

1 Comment

I am finding that on Windows, I can run git add --renormalize . at any time and it will accept all current file line endings.
0

In order to prevent me from wrong solution apply, I did (succesfully) the following:

# Force LF terminator > git config --global core.autocrlf false > git config --global core.eol lf # Project backup and (re)cloning (with right terminators) > mv myproject myproject.old > git clone <my-project-url> myproject # Check terminators > cd myproject > file myscript.sh > myscript.sh: Bourne-Again shell script, ASCII text executable # Remove old project (if you want) > cd .. > rm -rfv myproject.old
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.