How to change line-ending settings

Question

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

possible duplicate of [How do I force git to use LF instead of CR+LF under windows?](http://stackoverflow.com/questions/2517190/how-do-i-force-git-to-use-lf-instead-of-crlf-under-windows) — Alastair Irvine, Oct 13 '14 at 07:25
@Stephen default is false, [check](http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/) — وليد تاج الدين, Dec 21 '17 at 06:58
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. — JustAMartin, Aug 06 '18 at 08:11
Agree with @JustAMartin having the system messing with your line endings is a great way to introduce bugs that will take an entire day to track down and fix, as I just have. All decent editors and IDEs on Windows now fully support LF line endings nowadays, there is no need for this translation. — Neutrino, Oct 14 '19 at 12:49
@Neutrino I wish this was true, but one example of IDE that messes with your line endings (and doesn't offer a reasonable configuration option to turn this off) is Visual Studio. — Not a real meerkat, Nov 07 '19 at 20:21
Visual Studio has supported [.editorconfig](https://kent-boogaart.com/blog/editorconfig-reference-for-c-developers#end_of_line) files for ages. This is a really good way to configure text settings across all file types in a solution and is supported by all good editors. — Neutrino, Nov 08 '19 at 13:32
Agree with @JustAMartin. The default is especially bad if you use Docker for Windows. You'll end up copying CRLF files into a Docker image and get cryptic errors from the Linux util programs that try to process them. — Aurast, Jul 30 '20 at 17:23
@Aurast, in such a case, why not `input`? This always checkout files as they are in checked-in to **git**, `LF` for files that are `eol` converted. Pro tip, you can check the status of `eol` for all files tracked by **git** using `git ls-files --eol`. The first column `i/` is for the **index**, the stuff checked-id, `w/` is for the working tree, the stuff checked out — CervEd, May 03 '21 at 09:36
note that changing to `input`, doesn't change line-ending until that file is checked out again. So you have to checkout all files for this to take effect. The easiest way probably checking out the first commit, then back to HEAD of the curent branch `git rev-list HEAD | tail -1 | xargs git checkout && git switch -` — CervEd, May 03 '21 at 09:43
My personal experience is that `autoclrf false` creates a complete mess when used on Windows. Some files `CLRF` some `LF`. `autoclrf true` is a must if you're running two **VCS** or something else that is sensitive to line-ending changes. Most sensible Windows editors have no problem opening `LF` files. If they for some reason misbehave and revert to CLRF, no biggie, it get checked in as `LF` with `input` — CervEd, May 03 '21 at 10:07
I use `wsl` and have a system wide config `C:/git/etc/gitconfig` for both Linux and Windows. Can I set the `autocrlf` there or should I do two different settings in the `home` configs as Jasnan does with `input` and `true`? — Timo, Jun 02 '21 at 20:04
Just now I spent one hour trying to figure why my SH script was not running, This option should be completely removed. In 21st century, all good programming editors work with unix eof. — Daniel N., Apr 19 '22 at 23:20

score 766 · Accepted Answer · edited Jun 10 '23 at 14:45

766

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.

edited Jun 10 '23 at 14:45

Adil

127
1
8

answered May 02 '12 at 18:12

CodingWithSpike

42,906
18
101
138

74

`input` is the 3rd option (as stated in the link I provided). The 3 options are `true` | `false` | `input` – CodingWithSpike May 02 '12 at 18:15
4

Here is another good SO question on the subject: http://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operat – CodingWithSpike May 02 '12 at 18:16
37

Actually, if you re-read your own question, in the copy/pasted excerpts : `"1 ... ("core.autocrlf" is set to "true") ... 2 ... ("core.autocrlf" is set to "input") ... 3 ... ("core.autocrlf" is set to "false")"` so you basically answered your own question? :) – CodingWithSpike May 02 '12 at 18:26
2

Pro git has been absorbed by git-scm. An equivalent link to the git-scm book is the [formatting and whitespace configuration section](http://git-scm.com/book/en/Customizing-Git-Git-Configuration#Formatting-and-Whitespace). – bschlueter Feb 04 '14 at 20:30
You might want to use `--system` rather than `--global` in some settings. – SOFe Jun 06 '19 at 06:59
4

This is the old way to go around it. Look at .gitattributes file. – eftshift0 Oct 18 '19 at 03:07
this is especially visible where windows does not register any change, default endings in linux would change all the files, so it is useful to have the endings on both systems same either crlf, or only lf – FantomX1 Nov 19 '19 at 12:16
3

it should be noted that after changing this setting, it helps to `git rm --cached -r .` and then `git reset --hard` in order to rewrite all files in the working tree. You will lose uncommitted changes by doing this! – joki Jan 14 '21 at 09:31
I use `windows` and `linux` for my git repos, and `vscode` with always `lf` on both. I have `core.autocrlf` to `false` and it works, always using `lf`. – Timo Jun 04 '21 at 05:55

score 277 · Answer 2 · edited Aug 24 '23 at 00:04

277

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.

Git Global configuration
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 placed 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

edited Aug 24 '23 at 00:04

Josh Correia

3,807
3
33
50

answered Nov 26 '16 at 18:56

Jasnan

4,054
2
18
23

4

What about OS X, which uses `CR` (carriage return) alone? – jww Jun 02 '17 at 02:38
31

Legacy MacOS (that is, MacOS 9 and earlier) used `CR` alone, but OS X generally uses `LF`. – Zachary Ware Jun 11 '17 at 04:03
3

Can I use `* text eol=lf` twice to have it checkout with `LF` on Windows? – mbomb007 Nov 08 '18 at 19:46
6

According to [gitattributes documentation](https://git-scm.com/docs/gitattributes#Documentation/gitattributes.txt-Settostringvalueauto) setting `* text=auto` lets git decide whether the content is text or not. Forcing all files to be text should be `* text` only. – Adrian W Aug 08 '19 at 09:39
1

Which of those are off - leave my files alone - my files my line endings - don't change anything? – Martin Mar 26 '20 at 16:27
2

`The first one is for checkout and the second one is for commit.` Are you sure? I see no documentation supporting this – CervEd Oct 29 '21 at 10:12

score 39 · Answer 3 · edited May 23 '17 at 11:47

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?

`. - text` gives `is not a valid attribute name: .gitattributes:1` please put `cat .gitattributes` — jangorecki, Apr 15 '20 at 14:36

score 18 · Answer 4 · answered Jun 30 '21 at 01:05

18

The .gitattributes file

The easiest way is to use a local .gitattributes file in your repo.

You can also change line-endings for specific file extensions too

*           text=auto     # auto
*.txt       text
*.vcproj    text eol=crlf # windows line-endings
*.sh        text eol=lf   # linux line-endings
*.jpg       -text

This also overrides the global defaults, so it's much more portable and makes the repo more reliable on different machines.

answered Jun 30 '21 at 01:05

Ben Winding

10,208
4
80
67

5

You have to remove comments at the end of lines to prevent `# is not a valid attribute name: .gitattributes:1` errors during the checkout – Zoltán Barics Jun 04 '22 at 19:04
If you want to do it for files in a particular subfolder: `path/to/subfolder/*.sh`. Recursively: `path/to/subfolder/**/*.sh`. – stackprotector Aug 02 '22 at 13:24

score 13 · Answer 5 · answered Oct 23 '19 at 09:11

13

For me what did the trick was running the command

git config auto.crlf false

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

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

[auto]
    crlf = false

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

answered Oct 23 '19 at 09:11

Travel and code enthousiast

451
7
18

Thank you! I tried `core.autocrlf=false` which did not work for me in WSL, while GitBash and IntelliJ had no problem with that. – GameDroids Jul 28 '22 at 12:51

Captain Jack Sparrow · Answer 6 · 2023-05-22T19:06:52.633

3

For the option "checkout as is, commit as is" in Windows:

git config --global core.autocrlf false

This will not modify line endings at all.

edited May 22 '23 at 19:06

answered Jan 13 '23 at 19:46

Captain Jack Sparrow

971
1
11
28

score 2 · Answer 7 · edited Mar 02 '16 at 12:05

If you want to convert back the file formats which have been changed to UNIX Format from PC format.

(1)You need to reinstall tortoise GIT and in the "Line Ending Conversion" Section make sure that you have selected "Check out as is - Check in as is"option.

(2)and keep the remaining configurations as it is.

(3)once installation is done

(4)write all the file extensions which are converted to UNIX format into a text file (extensions.txt).

ex:*.dsp
   *.dsw

(5) copy the file into your clone Run the following command in GITBASH

while read -r a;
do
find . -type f -name "$a" -exec dos2unix {} \;
done<extension.txt

score 1 · Answer 8 · answered Jul 08 '21 at 09:13

Below steps work for me

Add a git attributes on root project folder (it will be useful for upcoming file)

* text=auto

*.tf  eol=lf
*.tfvars  eol=lf
*.yml  eol=lf

After execute below command for give a support to already exist files

find ./ -type f \( -iname \*.tf -o -iname \*.tfvars -o -iname \*.md -o -iname \*.yml \) -print0 | xargs -0 dos2unix

dos2unix .gitignore
dos2unix .gitattributes