Git replacing LF with CRLF

Question

On a Windows machine, I added some files using git add. I got warnings saying:

LF will be replaced by CRLF

What are the ramifications of this conversion?

Othaothe

@apphacker because standardising line-endings is less annoying than having to change them yourself when diffing two files. (And of course, if you disagree, then you can keep the core.autocrlf feature off). – Cl

why would the line endings be different unless the entire line was touched – Confucianism

I often touch lots of lines, because I'm experimenting with different ideas, adding trace statements to see how they work, etc. Then I might want to only commit a change to two or three lines and have git completely ignore the others because I had put them back they way I found them (or so I thought). – Granduncle

An upstream discussion of the same issue: kerneltrap.org/mailarchive/git/2008/4/16/1450834/thread – Enjoy

@MatrixFrog: your editor seems broken, unable to autodetect line endings. Which is it? I work on hybrid projects which must have some LF files and some other CRLF files in the same repo. Not a problem for any modern editor. Having version control (or file transfer) mess with line endings to work around editor limitations is the worst idea ever - obvious from the mere length of the explanations below. – Oleviaolfaction

The only modern editor I know about that does the wrong thing is Visual Studio. Visual Studio will happily open a file with LF line endings. If you then insert new lines, it will insert CRLF, and save out mixed line endings. Microsoft refuses to fix this, which is a pretty big blemish on an otherwise pretty good IDE :--( – Labialize

Similar question #9977486 has more details on how to reset git index and line breaks handling on working copy while preserving files. – Annabal

Upstream discussion was at kerneltrap; that seems to be gone now. Wayback archive: web.archive.org/web/20110805073326/http://kerneltrap.org/… – Stubbs

Does this issue persist on 2020, ten years after the original question? – Tephra

Fix is on this page but some pagedowns later https://mcmap.net/q/11212/-git-replacing-lf-with-crlf – Nolanolan

I love a question with still no clear-cut answer after 14 years, and 200 comments of people all disagreeing and saying each other's solutions don't work. – Devisal

Potentially big ramifications... – Mendelson

Answer 1

These messages are due to an incorrect default value of core.autocrlf on Windows.

The concept of autocrlf is to handle line endings conversions transparently. And it does!

Bad news: the value needs to be configured manually.

Good news: it should only be done one time per Git installation (per project setting is also possible).

How autocrlf works:

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

     repository               repository               repository
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \
   /            \           /            \           /            \

Here crlf = win-style end-of-line marker, lf = unix-style (also used on Mac since Mac OS X).

(pre-osx cr is not affected for any of three options above.)

When does this warning show up (under Windows)?

    – autocrlf = true if you have unix-style lf in one of your files (= RARELY),
    – autocrlf = input if you have win-style crlf in one of your files (= almost ALWAYS),
    – autocrlf = false – NEVER!

What does this warning mean?

The warning "LF will be replaced by CRLF" says that you (having autocrlf=true) will lose your unix-style LF after commit-checkout cycle (it will be replaced by windows-style CRLF). Git doesn't expect you to use unix-style LF under Windows.

The warning "CRLF will be replaced by LF" says that you (having autocrlf=input) will lose your windows-style CRLF after a commit-checkout cycle (it will be replaced by unix-style LF). Don't use input under Windows.

Yet another way to show how autocrlf works

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

where x is either CRLF (windows-style) or LF (unix-style) and arrows stand for

file to commit -> repository -> checked out file

How to fix

The default value for core.autocrlf is selected during Git installation and stored in system-wide gitconfig (%ProgramFiles(x86)%\git\etc\gitconfig on Windows, /etc/gitconfig on Linux). Also there're (cascading in the following order):

   – "global" (per-user) gitconfig located at ~/.gitconfig, yet another
   – "global" (per-user) gitconfig at $XDG_CONFIG_HOME/git/config or $HOME/.config/git/config and
   – "local" (per-repo) gitconfig at .git/config in the working directory.

So, write git config core.autocrlf in the working directory to check the currently used value and

   – git config --system core.autocrlf false            # per-system solution
   – git config --global core.autocrlf false            # per-user solution
   – git config --local core.autocrlf false              # per-project solution

Warnings

    – git config settings can be overridden by gitattributes settings.
    – crlf -> lf conversion only happens when adding new files, crlf files already existing in the repo aren't affected.

Moral (for Windows):

    - use core.autocrlf = true if you plan to use this project under Unix as well (and unwilling to configure your editor/IDE to use unix line endings),
    - use core.autocrlf = false if you plan to use this project under Windows only (or you have configured your editor/IDE to use unix line endings),
    - never use core.autocrlf = input unless you have a good reason to (eg if you're using unix utilities under Windows or if you run into makefiles issues),

PS What to choose when installing Git for Windows?

If you're not going to use any of your projects under Unix, don't agree with the default first option. Choose the third one (Checkout as-is, commit as-is). You won't see this message. Ever.

PPS: My personal preference is configuring the editor/IDE to use unix-style endings, and setting core.autocrlf to false.

Update(2022)

Since 2018, git can --renormalize repo fixing the existing line endings as required.

Coff

This is so confusing. I have LF set in my editor. All the repo code uses LF. global autocrlf is set to false and the core gitconfig in my home dir is set to false. But I still get message LF being replaced with CRLF – Mooned

Did you check the local (per-project) autocrlf? – Coff

git config core.autocrlf=false gives an error. It should be: git config core.autocrlf false (space instead of '=') – Jugurtha

If you've configured your editor to use Unix style endings, why not set core.autocrlf to input? From what I gathered from your answer, setting it to input makes sure the repository and the working directory always has unix-style line endings. Why would you never want that in Windows? – Mezzosoprano

That's because bizzare errors I can potentially get (eg Cannot remove worktree changes) and impossibility to have both types of line endings in one project (eg .bat and .sh files) outweight the presence of evident warnings that I can't get anyway in my normal workflow. – Coff

As a workaround I'd suggest cloning the repository. That will replace all LFs by CRLFs and the warning will not show up unless the editor adds them again. – Coff

Something's odd though. I have core.autocrlf set to false in both global and local config, but I still get the warning when trying to commit. git version is 2.7.0 – Maritsa

Figured it out: .gitattributes can override the config settings. – Maritsa

I agree with Hubro: great explanation, but I don't see why the right outcome would not be "set to input when IDE configured to use LF, never ever use false". I don't understand how, after everything you've outlined, you can come to the conclusion never to use input. – Solidarity

@hheimbuerger LF is unix line endings. input only converts CRLF to LF, but not the other way round. There's no profit of using input if your line endings are already LF. – Coff

@AntonyHatchkins The profit is that input will convert my line endings, should I ever accidentally have a CRLF somewhere (maybe you once make a quick edit in Notepad instead of your nicely configured IDE!), while not affecting all the intentional LFs. The downside of using false would be that if I ever have an accidental CRLF, I might accidentally commit it to the repo. input would prevent that! So input > false, no? – Solidarity

@hheimbuerger Me? Notepad? Never :) I only thing I use notepad for is getting rid of non-textual content (eg hyperlinks) in the clipboard by pasting to and then copying from the notepad. – Coff

@hheimbuerger Actually wrong line endings are rarely a trouble. So for me personally in most cases the annoyance of this message overweights the profit of using it. But in an unlikely case when it can lead to a trouble (eg linux makefiles) it's a bad habit to rely on vcs in this matter. A much better way would be to configure the editor (all the editors you might use) once in a lifetime to use lineendings you need. – Coff

@AntonyHatchkins That doesn't explain why false is better than input. Both are configurations of your VCS, so saying "it's a bad habit to rely on the VCS" is a weird argument to make on a discussion that's entirely about VCS configuration. Even if you think you shouldn't rely on it, you still need to pick one of the two. – Solidarity

@hheimbuerger It looks as if you aren't willing to hear what I say. "False" is better because it doesn't show the annoying message. To rely on vcs in this matter only. It's your personal choice what option to use. I gave my reasons. You are free to have yours. – Coff

Here's an example. In the project I'm working with there's a lot of html files (in addition to my python files). A person who's responsible for those files is working on Windows, I usually work on Linux, but sometimes on Windows as well. input option will convert his crlf's to lf's even every time I commit my changes even if they have nothing to do with those html files. And it will mark all his files as changed in history as well as break his normal workflow. It's a bad practice to automatically inject changes to the files you're not responsible for. – Coff

@AntonyHatchkins I can tell you've never tried opening and LF file in notepad. It's impossible to read, let alone make an edit. But yes, it can happen by mistake if your editor gets confused. Incidentally, another reason to use false is if your team uses subversion in a Windows environment, but you want to use Git. You need to commit in CRLF in that case, so Subversion (and team members) see the right line endings. – Mallen

@Mallen Yes, I opened an LF file in notepad a couple of times - by mistake. I can't imaging anyone using notepad for anything useful. I only use it for stripping formatting from clipboard :) And yes, that's a good example of using false – Coff

On Windows Vista or newer the system gitconfig can instead be found at C:\ProgramData\Git\config – Thomasina

For explanation this is a good answer; for recommendation it's badly out of date — see why gitattributes supercedes autocrlf – Bushing

How do I configure vs code to have unix style endings? @AntonyHatchkins And what should I do with an existing project where line endings have been converted to CRLF by git – Mat

@Mat This SO question deals with configuring VS Code, this extension converts line endings in all files – Coff

@Mezzosoprano Because it silently changes files, this is not a good thing. The files with CRLF endings should be keep that way. Otherwise you risk make batch files not working anymore and may change binary files. I saw many cases of something changing LF to CRLF or vise versa causing some bugs somewhere else. Set it to false and use LF for all possible text files by setting the editor to use LF. – Capers

My Parser crashed trying to figure out relation between your Moral section and config setting during setup, but don't worry, git document wasn't any better either. – Gertudegerty

@Aaa Could you describe your usecase? Are you on windows? – Coff

You see, I know what options I need to set during setup (AS-IS) but I can't figure out which of 3 options you mentioned is that one. As I said, your text isn't wrong, it helps people decide what they need. however since I already know which option I supposed to choose in setup, I wanted to know which option is that one in git configuration files. Since most advanced IDE already supports all line ending cases, I don't want git change any of my codes, It is like someone come and arrange your table for you and say "there! I fixed it for you! you'll thank me later!" – Gertudegerty

@Gertudegerty Ok, I see. Yet it is still not 100% clear to me what you suggest. Should I highlight that "core.autocrlf = false" and "AS-IS" is the same thing in the moral section? If so, I'll do it otherwize plz edit the post to make it clearer. It is a community wiki after all! – Coff

Not at all, your document is clear enough. I was trying to figure out something that might not be interesting to anyone other than me. – Gertudegerty

You might also find this playground for all git line-ending settings helpful: hediet.github.io/git-line-endings – Edwin

@Batish At which level did you apply this setting? Are you sure you have only one installation of git on your machine? – Coff

I'm editing code on Windows, but running it via a WSL2 docker volume. I agree with others about the input value - saying "don't use input under windows" doesn't seem to be very helpful. In my case, I DO want to use LF endings under windows - because although I'm editing the code in windows, it's running in Linux (on the same machine via a shared folder). Also (just me being pedantic) saying never and then giving a caveat turns it into a sometimes. – Tippett

@LouisSayers Why don't you use autocrlf=true in your setup? If lf->crlf conversion is done by your editor, git diff will have troubles checking the differences in the changed file. – Coff

@AntonyHatchkins - I don't want to accidentally have a file with windows line-endings committed and I can't envision a scenario for my project where that would change. My editor uses LF endings, not CRLF - even in windows. – Tippett

@LouisSayers As I mentioned above, basically there're two reasons: (1) Setting it to input makes it impossible to have two types of line endings in one project (windows bat files and linux shell scripts). (2) People report cases when this option corrupts binary files erronously marked as text files. For me those two corner cases are enough to recommend to avoid setting this option to input. YMMV. – Coff

@AntonyHatchkins So if I were to rephrase what you just wrote, you could say: "If you only want Linux line endings in your project, and you absolutely do not want Windows line endings (i.e. you will never have any bat files, Windows binaries or other Windows files in your project), then it is recommended to use the input option". – Tippett

@LouisSayers I consider allowing version control system to control line endings instead of versions to be a bad design decision. Even worse - to make it enabled by default. And yet the worst of them all - to make it asymmetric as with the input option. The source of the windows line endings problem is the editor. Delegating it to VCS hides the problem rather than solving it. One day it'll shoot the unwary user in the feet (see two examples above). Even if you personally don't plan to add windows scripts and don't have binary files it doesn't mean another collaborator won't do it. – Coff

DIDN'T WORK? core.autocrlf wasn't enough for me (Docker had issues with Laravel migrations). I'm on Windows and in my case I needed everything to remain in LF mode, so $ git config --global core.eol lf did the trick. I also added a * text=auto line to .gitattributes file. – Parra

I have autocrlf=false in my repo (but it's set to true globally) and I still get this warning when stashing (with git stash) changes: LF will be replaced by CRLF. Any ideas why I get this? – Increase

@sapeish what does your git config core.autocrlf say (in the project dir)? What is your OS? – Coff

Thanks. Otherwise, I still don't understand this subject. On Windows 10 I have set autocrlf to false. In the git repos I sometimes have files that use LF (Linux shell scripts fail if CRLF is used) and Visual Studio stuff that uses CRLF. The other time, I had automatic CRLF set to true (default) but I couldn't commit a shell script file where LF (in the remote repo) was changed to CRLF locally by git (fortunately) that's why I'm confused, in fact I changed the CRLF to LF with notepad++ but git shows me something to be commited and when I do so it doesn't commit, I hope I'm clear. – Booty

@Aminos. Not entirely clear. One time you had autocrlf=false and had no problems, the other time you had autocrlf=true and had problems. This is sort of in line with this answer that says "don't have autocrlf=true. Set it to false." – Coff

I have core.autocrlf=false by habit and I still get to see this every once in a while (despite not locally overriding it for the repos I work with). What gives? Your answer claims that I should never see it?! – Lurk

@Lurk Check you config files for typos, your system for duplicate git installations, and raise a ticket in git issue tracker if nothing helps. When raising a ticket, be more specific than 'I have this by habit'. Is it a per-project, per-system, per-user setting? Does it sit in the correct section of the config file? Etc. – Coff

Just set it to false. It creates more problems than it solves. Git should not be mutating files other than changes explicitly made by users. – Friesian

Can a .gitattributes punctually overwrite this rules for some files? – Gesticulation

A Incredible answer.Thk u – Freightage

Answer 2

Git has three modes of how it treats line endings:

# This command will print "true" or "false" or "input"
git config core.autocrlf

You can set the mode to use by adding an additional parameter of true or false to the above command line.

If core.autocrlf is set to true, that means that any time you add a file to the Git repository that Git thinks is a text file, it will turn all CRLF line endings to just LF before it stores it in the commit. Whenever you git checkout something, all text files automatically will have their LF line endings converted to CRLF endings. This allows development of a project across platforms that use different line-ending styles without commits being very noisy, because each editor changes the line ending style as the line ending style is always consistently LF.

The side effect of this convenient conversion, and this is what the warning you're seeing is about, is that if a text file you authored originally had LF endings instead of CRLF, it will be stored with LF as usual, but when checked out later it will have CRLF endings. For normal text files this is usually just fine. The warning is a "for your information" in this case, but in case Git incorrectly assesses a binary file to be a text file, it is an important warning, because Git would then be corrupting your binary file.

If core.autocrlf is set to false, no line-ending conversion is ever performed, so text files are checked in as-is. This usually works ok, as long as all your developers are either on Linux or all on Windows. But in my experience I still tend to get text files with mixed line endings that end up causing problems.

My personal preference is to leave the setting turned ON, as a Windows developer.

See git-config for updated information that includes the "input" value.

Shortage

As said here (#1250432), I would respectfully disagree and leave that setting to OFF (and use Notepad++ or any other editor able to deal with -- and leave as it is -- whatever end line character it finds) – Granular

I like this answer, and prefer to leave autocrlf set to true. As an alternative, is there a way to kill the warning messages automatically? – Davon

It would be nice to augment this well-written answer with a comparison to the core.eol settings, perhaps in concert with .gitattributes configuration. I've been trying to figure out the differences and overlaps through experimentation, and it's very confusing. – Woolson

As seh points out, core.autocrlf isn't the only thing that can cause git to change line endings. Among other things, run "git help attributes" and search for "end-of-line normalization"; that document is quite thorough, though you might need to supplemental googling to understand it all. – Scribe

@seh, i'm not familiar with core.eol and .gitattributes, but you can opt to edit the answer and wait for moderator approval. It would be more appropriate if this was community wiki – Banff

For a more permanent solution change your .gitconfig to: [core] autocrlf = false – Florettaflorette

git man "This variable can be set to input, in which case no output conversion is performed." – Londonderry

Linux developers will want to set it on false or input. Better be set the same way by Windows developers as modern IDEs can handle Unix line endings. – Londonderry

I would argue that if you're a PHP developer and want your code to be PSR-2 compliant, you have to use LF line endings. I'm dealing with PHP on Windows and set that feature off as soon as I learned about it, since my editor is able to deal with LF line endings. – Linderman

So basically, based on the accepted answer, the message "LF will be replaced by CRLF" means "Next time this file will be checkout, LF will be replaced by CRLF", right ? – Embus

Is there any easy way to just squelch the warning? I want it to true and know that I have set it to true. I don't need to see all the warnings all the time... It's OK, really... :p – Shonna

To change the setting system-wide: git config --global core.autocrlf true/false/input – Toluol

This didn't work for me, but this one does: https://mcmap.net/q/11226/-git-how-do-i-get-rid-of-quot-warning-crlf-will-be-replaced-by-lf-quot-without-disabling-safecrlf – Secondhand

Why does the message say that LF -> CRLF conversion will be made? Since working in the windows environment, isn't the conversion CRLF -> LF when adding files to repo? – Phylloxera

Linux users can follow VonC's advice by using Kate. Tools->End Of Line->Unix – Butterflies

@Davon Late answer, but the way to suppress just the warnings is setting core.safecrlf to false: https://mcmap.net/q/13123/-with-git-how-do-i-turn-off-the-quot-lf-will-be-replaced-by-crlf-quot-warning – Holeproof

One important clarification is that even if autocrlf=true, during add/commit, only new files get converted from CRLF to LF. Existing CRLF files will stay CRLF even if modified and committed. – Deafening

@Deafening I don't think that's consistent with my experience. But lately I've obsessively made sure we have a .gitattributes file with * text=auto in all my repos so I guess I'm a bit fuzzy on the behavior without one. – Shortage

Answer 3

If you already have checked out the code, the files are already indexed. After changing your Git settings, say by running:

git config --global core.autocrlf input

You should refresh the indexes with

git rm --cached -r .

And rewrite the Git index with

git reset --hard

Note: this will remove your local changes. Consider stashing them before you do this.

---

Source: Configuring Git to Handle Line Endings

Bales

if git reset --hard is it possible my local change will be lost ? i just follow all comment metion above – Kaycekaycee

Yes your local changes will be lost. The --hard parameter resets the index and the working tree so any changes to tracked files will be discarded. git-scm.com/docs/git-reset – Mabelmabelle

@FreddySidauruk You should double check whenever using the --hard or --force flags with Git. – Donley

What is meaning of git rm --cached -r .? Why git reset --hard isn't enough? – Chevet

@Chevet the rm removes all tracked files recursively. You're right that it's probably not needed – Unmentionable

@Chevet @max You need the git rm --cached -r . If you do git reset --hard after changing the core.autocrlf setting, it will not re-convert the line endings. You need to clean the git index. – Deafening

@Bales - thanks for this - All should note that the link provided has changed its directions; the new directions don't really make any sense and are inconsistent. This answer works well if your goal is to get an existing local repo to refresh both the index and working copies. You want that so that all of your local files, and the cache, reflect the new line-ending policies. – Halfbaked

THIS! (after you've set core.autocrlf). If you're on SourceTree, you might also want to make sure you told it to use System Git instead of Embedded Git – Encephalic

The link you provided (about refreshing the repository after changing core.autocrlf configuration) does not use the commands you suggest but rather uses git add --renormalize . So maybe the recommended procedure has changed since 2015? @Bales maybe you can elaborate on the difference. – Dowsabel

thanks you saved. I recently shifted from Linux to Windows since my stack has graphics needs too. And code base was getting all these LF errors, and I didnt wanted to push file format change in 100+ files. This saved me <3 – Anastigmat

This is the only thing that worked for me in a repo on windows that was already checked out with CRLF instead of LF. git add --renormalize . didn't fix it. – Skylark

Answer 4

git config core.autocrlf false

Shameful

make sure to run this inside repository root – Metage

I don't understand how this can be useful. Half the people require autocrlf to be true for it to work, the other half need it to be false/input. So, what, are they supposed to randomly throw these one-off answers onto their console wall until something sticks and sorta "works" ? This is not productive. – Aldis

I get an error "fatal: not in a git directory". I tried to cd to C:\Program Files\Git and C:\Program Files\Git\bin – Kurr

@mbb setting autcrlf to false just punts the issue to every user of your project. – Mallen

@Kurr : this command is setting the property only for the project (so you need to be under a git repository to run it). If you want to set this globally, use git config --global core.autocrlf false instead. – Embroider

Answer 5

Both unix2dos and dos2unix is available on Windows with Git Bash. You can use the following command to perform UNIX (LF) → DOS (CRLF) conversion. Hence, you will not get the warning.

unix2dos filename

or

dos2unix -D filename

But, don't run this command on any existing CRLF file, because then you will get empty newlines every second line.

dos2unix -D filename will not work with every operating system. Please check this link for compatibility.

If for some reason you need to force the command then use --force. If it says invalid then use -f.

Authorize

Here's what the help option says: ` --u2d, -D perform UNIX -> DOS conversion` – Shatter

@LarryBattle u2d and d2u is not the same thing I believe. – Authorize

@Authorize I'm confused. Your comment says that dos2unix -D will convert windows line endings to linux line endings. Isn't that the same as DOS(CRLF) -> UNIX(LF) conversion. However dos2unix -h states that -D will perform UNIX(LF) -> DOS(CRLF) conversion. dos2unix More info: gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix – Shatter

@LarryBattle Yes, you are right about -D. Actually, I posted the answer when I was a windows user. And, I made the comment more than a year later when I'm a mac user :D BTW, Thanks for the clarification. – Authorize

@LarryBattle I've deleted my comment because It could mislead people. – Authorize

This worked for me. I'm using Cygwin, which doesn't seem to support the -D switch - but there is the "unix2dos" command, which does the same thing. I wish I knew what caused the problem though - I have core.autocrlf = false and it's a Windows-only repository. – Niall

This answer could be significantly improved with the information in the comments – Squatter

In my Git Bash console, dos2unix -D filename works as supposed only for ASCII files. If the file is UTF-8 and already in DOS format (CRLF), then it will be converted to... CRCRLF (!) which will look like empty newlines every second line. As of Msysgit 1.7.11. YMMV. – Fruitful

I'm using Windows Bash, which doesn't seem to support the -D or ` --u2d` switch in dos2unix 6.0.4 (2013-12-30) – Perfumer

Answer 6

A GitHub article on line endings is commonly mentioned when talking about this topic.

My personal experience with using the often recommended core.autocrlf configuration setting was very mixed.

I'm using Windows with Cygwin, dealing with both Windows and Unix projects at different times. Even my Windows projects sometimes use Bash shell scripts, which require Unix (LF) line endings.

Using GitHub's recommended core.autocrlf setting for Windows, if I check out a Unix project (which does work perfectly on Cygwin - or maybe I'm contributing to a project that I use on my Linux server), the text files are checked out with Windows (CRLF) line endings, creating problems.

Basically, for a mixed environment like I have, setting the global core.autocrlf to any of the options will not work well in some cases. This option might be set on a local (repository) Git configuration, but even that wouldn't be good enough for a project that contains both Windows- and Unix-related stuff (e.g., I have a Windows project with some Bash utility scripts).

The best choice I've found is to create per-repository .gitattributes files. The GitHub article mentions it.

Example from that article:

# 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

In one of my project's repository:

* text=auto

*.txt         text eol=lf
*.xml         text eol=lf
*.json        text eol=lf
*.properties  text eol=lf
*.conf        text eol=lf

*.awk  text eol=lf
*.sed  text eol=lf
*.sh   text eol=lf

*.png  binary
*.jpg  binary

*.p12  binary

It's a bit more things to set up, but do it once per project, and any contributor on any OS should have no troubles with line endings when working with this project.

Passion

Running into this now, trying to manage a repo with Cygwin scripts among other basic text files. How would you handle files with no extension (e.g. "fstab", "sshd_config")? The linked article doesn't cover that scenario. – Crocidolite

@MikeLoux Try this method: https://mcmap.net/q/11228/-files-without-extensions-in-gitattributes – Passion

I found that text=false eol=false worked somewhat similarly to binary. Does that sound right? It might be useful to indicate "I know these are text files, but I don't want them to be normalised" – Poodle

Answer 7

I think Basiloungas's answer is close, but out of date (at least on Mac).

Open the ~/.gitconfig file and set safecrlf to false:

[core]
       autocrlf = input
       safecrlf = false

That *will make it ignore the end of line char apparently (it worked for me, anyway).

Donica

It should be safecrlf (with an 'f') – Osmund

Answer 8

In Vim, open the file (e.g.: :e YOURFILEENTER), then

:set noendofline binary
:wq

Mercer

Simply editing with vim would leave all line ending intact. – Ardolino

I've been having this problem with some Cocoapods files. The above fixed most of them; for the rest, s/{control-v}{control-m}// did the trick. The two control codes together make the ^M that those of us on OS X often see in Windows files. – Mills

Answer 9

I had this problem too.

SVN doesn't do any line ending conversion, so files are committed with CRLF line endings intact. If you then use git-svn to put the project into git then the CRLF endings persist across into the git repository, which is not the state git expects to find itself in - the default being to only have unix/linux (LF) line endings checked in.

When you then check out the files on windows, the autocrlf conversion leaves the files intact (as they already have the correct endings for the current platform), however the process that decides whether there is a difference with the checked in files performs the reverse conversion before comparing, resulting in comparing what it thinks is an LF in the checked out file with an unexpected CRLF in the repository.

As far as I can see your choices are:

1. Re-import your code into a new git repository without using git-svn, this will mean line endings are converted in the intial git commit --all
2. Set autocrlf to false, and ignore the fact that the line endings are not in git's preferred style
3. Check out your files with autocrlf off, fix all the line endings, check everything back in, and turn it back on again.
4. Rewrite your repository's history so that the original commit no longer contains the CRLF that git wasn't expecting. (The usual caveats about history rewriting apply)

---

Footnote: if you choose option #2 then my experience is that some of the ancillary tools (rebase, patch etc) do not cope with CRLF files and you will end up sooner or later with files with a mix of CRLF and LF (inconsistent line endings). I know of no way of getting the best of both.

Enjoy

I think there's a 4th option to add to your list, assuming one can afford to rewrite history: You can take a git repo that you initially created with git-svn, and rewrite its history to no longer have CRLF linefeeds. This would give you normalized linefeeds extending backwards through your whole svn history. User keo presents one solution at https://mcmap.net/q/11237/-line-endings-messed-up-in-git-how-to-track-changes-from-another-branch-after-a-huge-line-ending-fix. – Scribe

About your footnote: rebase has no problem with CRLF. The only problem I know of is that the standard git merge tool will insert its conflict markers ("<<<<<<", ">>>>>>" etc.) with LF only, so a file with conflict markers will have mixed line endings. However, once you remove the markers, everything is fine. – Silicic

It's possible git's handling has changed in the last 3 years, this was my direct experience with it at the time, I haven't had need to revisit this particular issue since. ymmv. – Enjoy

@Silicic starting git 2.8, the merge markers will no longer introduce mixed line ending. See https://mcmap.net/q/11231/-make-git-use-crlf-on-its-quot-lt-lt-lt-lt-lt-lt-lt-head-quot-merge-lines – Granular

@VonC: That's cool. Good to know for the times I need to work on Windows. – Silicic

Answer 10

Most of the tools in Windows also accepts a simple LF in text files. For example, you can control the behaviour for Visual Studio in a file named '.editorconfig' with following example content (part):

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

Only the original Windows Notepad does not work with LF, but there are some more proper simple editor tools available!

Hence you should use LF in text files in Windows too. This is my message, and it is strongly recommended! There isn’t any reason to use CRLF in windows!

(The same discussion is using \ in include paths in C/++. It is bovine fecal matter. Use #include <pathTo/myheader.h> with slash!, It is the C/++ standard and all Microsoft compilers support it).

Hence the proper setting for Git is:

git config core.autocrlf false

My message: Forget such old thinking programs as dos2unix and unix2dos. Clarify in your team that LF is proper to use under Windows.

Delamare

Answer 11

Removing the below from the ~/.gitattributes file,

* text=auto

will prevent Git from checking line-endings in the first place.

Indusium

Incorrect. That line, if present, will override the configuration of core.autocrlf. If that is set to 'true', then no, removing that line won't prevent git from checking line endings. – Guddle

Nonetheless, if core.autocrlf is set to false, if this one is not removed setting the autocrlf to false won't help much, so this one helped me (but is on its own not enough). – Unerring

Upvoting this!! While the "will prevent git from checking" part isn't technically correct, this is the ONLY answer that specifically mentions the text= setting in .gitattributes at all (which, if present, WILL be a blocker). So the other answers are incomplete. I was going nuts trying figure out why my files continued to show up as "modified" no matter how many times I changed my autocrlf and safecrlf settings & checked out & cleared the git cache & hard reset. – Dauphin

Answer 12

How to make Git ignore different line endings

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/ (Not working)

You can disable the CRLF behaviour completely, or per filetype by changing entries in your .gitattributes file. In my case, I put this:

• -crlf This tells Git to ignore the line endings for all files. And does not change the files in your working directory. Even if you have the core.autocrlf set to true, false, or input.

echo "* -crlf" > .gitattributes

Do this on a separate commit or Git might still see whole files as modified when you make a single change (depending on if you have changed the autocrlf option).

This one really works. Git will respect the line endings in mixed line ending projects and not warn you about them.

Weinstein

This is especially useful when you want to convert between CRLF and LF, but you have a few .sh files that must stay intact. I use *.sh -crlf all the time... – Bedraggle

Best solution. Combined with git rm --cached -r . and git reset --hard it works for everybody in the project. – Spates

The second link is broken: "500 Internal Server Error" – Fireproof

Hi @PeterMortensen, regarding your edits, as git is command line program that has it's origins in case sensitive environments, wouldn't it make sense to refer to it as 'git' instead of 'Git'? – Weinstein

Answer 13

I don't know much about Git on Windows, but...

It appears to me that Git is converting the return format to match that of the running platform (Windows). CRLF is the default return format on Windows, while LF is the default return format for most other OSes.

Chances are, the return format will be adjusted properly when the code is moved to another system. I also reckon Git is smart enough to keep binary files intact rather than trying to convert LFs to CRLFs in, say, JPEG files.

In summary, you probably don't need to fret too much over this conversion. However, if you go to archive your project as a tarball, fellow coders would probably appreciate having LF line terminators rather than CRLF. Depending on how much you care (and depending on you not using Notepad), you might want to set Git to use LF returns if you can :)

Appendix: CR is ASCII code 13, LF is ASCII code 10. Thus, CRLF is two bytes, while LF is one.

Tempo

Since no one seems to have said it, CR stands for "Carriage Return" and LF stands for "Line Feed". As a second note, many windows editors will silently change a text file with the LF character denoting a newline to instead be the pair of characters CRLF. The user of the editor won't even be warned, but Git will see the change. – Botryoidal

Windows uses CRLF (Carriage Return / Line Feed - think mechanical typewriter). Mac uses CR, *nix uses LF...and this war will outlast all others... – Mendelson

@skeetastax: Mac doesn't use CR anymore. It uses LF, like Unix. So the war may outlast all others, but it seems that one of the combatants has capitulated. Now if we could only stamp out CRLF everywhere... (Please, everybody, if you maintain any program on Windows, make sure it accepts LF based files without problems, and ideally also make sure it has an option to generate LF based files also!) – Zorina

@SomeGuy Although, one could argue that dropping CR is not in keeping with the 'spirit' of the typewriting 'character' it represents, because just using LF on a typewriter only moves the paper up (and the 'cursor' down, relatively speaking), but you need to also move the carriage (with the paper in it) back to the right (the cursor to the left, relatively speaking) so you can start typing back at the left side of the page...so one could *legitimately argue that CRLF is actually more correct than using just CR or LF on their own... Just sayin'... ;P – Mendelson

@skeetastax: Although I might agree with you if we were still in a world of printing line-by-line on dot-matrix printers, in general the world has moved on, and almost all programming languages only really care that one line has ended and another line has begun. Having two characters do the job of one just wastes space in text files on disk (that will never be printed out), and creates new weird edge cases that need to be handled (what if the file sometimes contains missing CR chars before an LF, etc.). We would be far better off just standardizing on a single char, and LF has much precedent. – Zorina

Answer 14

It should read:

warning: (If you check it out/or clone to another folder with your current core.autocrlf being true,)LF will be replaced by CRLF

The file will have its original line endings in your (current) working directory.

This picture should explain what it means.

Loveinamist

It also means that what is sent up to Subversion (if you do that) will have the conversion. – Mallen

Answer 15

Make sure that you have installed the latest version of Git

I did as in a previous answer, git config core.autocrlf false, when using Git (version 2.7.1), but it did not work.

Then it works now when upgrading git (from 2.7.1 to 2.20.1).

Implicative

I think you meant you had git 2.17.1. I was having the same issue and did the update and this fixed it as well. Glad I saw your answer! – Retrochoir

Answer 16

CRLF could cause some problem while using your "code" in two different OSes (Linux and Windows).

My Python script was written in a Linux Docker container and then pushed using Windows' Git Bash. It gave me the warning that LF will be replaced by CRLF. I didn't give it much thought, but then when I started the script later, it said:

/usr/bin/env: 'python\r': No such file or directory

Now that is an \r for ramification for you. Windows uses "CR" - carriage return - on top of '\n' as new line character - \n\r. That's something you might have to consider.

Trigon

This should be emphasized more! It is common for a windows developer to use docker and bring up linux containers -- and if you bring a shell script in with git and it converts the LF to CRLF, it will break. – After

Answer 17

Other answers are fantastic for the general concept. I ran into a problem where after updating the warning still happened on existing repositories which had commits in previous setting.

Adding with --renormalize helped, e.g.,

git add --renormalize .

From the documentation:

" Apply the "clean" process freshly to all tracked files to forcibly add them again to the index. This is useful after changing core.autocrlf configuration or the text attribute in order to correct files added with wrong CRLF/LF line endings. This option implies -u."

Batish

True it has been changed. This commands works for me as well. – Guerin

Answer 18

I just had the same error. It happened after installing NVM NVM on Windows 10.

Setting the autoclrf in all levels did not worked.

In CMD I used: git ls-files --eol

i/lf    w/crlf  attr/             src/components/quotes/ExQuoteForm.js
i/lf    w/lf    attr/             src/components/quotes/HighlightedQuote.js

Conclusion:

Files I made have the different ending.

To change the files and reset, do

git config core.autocrlf false
git rm --cached -r .
git reset --hard

Although:

In some projects I needed to delete the repository and start it fresh.

Secretariat

Answer 19

1. Open the file in Notepad++.
2. Go to menu Edit → EOL Conversion.
3. Click on the Windows Format.
4. Save the file.

Trinia

Also try using git config --global core.autocrlf false to prevent Git from setting the line endings to Unix on a commit. Follow up with git config core.autocrlf to check it is indeed set to false. – Exothermic

Answer 20

The OP's question is Windows-related and I could not use others without going to the directory or even running file in Notepad++ as administrator did not work...

So had to go this route:

cd "C:\Program Files (x86)\Git\etc"
git config --global core.autocrlf false

Unders

Answer 21

Many text editors allow you to change to LF. See the Atom instructions below. It is simple and explicit.

---

Click CRLF on the bottom right:

Select LF in dropdown on top:

Traceetracer

Answer 22

In a GNU/Linux shell prompt, the dos2unix and unix2dos commands allow you to easily convert/format your files coming from MS Windows.

Facient

They are not installed by default in some versions of Ubuntu (and possibly many other Linux distributions). – Fireproof

Answer 23

CR and LF are a special set of characters that helps format our code.

CR (\r) puts the cursor at the beginning of a line but doesn't create a new line. This was how legacy versions of macOS (not-applicable today) works.

LF (\n) creates a new line, but it doesn't put the cursor at the beginning of that line. The cursor stays back at the end of the last line. This is how Unix (which includes macOS) and Linux work.

CRLF (\r\n) creates a new line as well as puts the cursor at the beginning of the new line. This is how we see it in Windows OS.

To summarize:

1. LF (LINE FEED)

• stands for Line Feed
• denoted with \n
• creates a new line in the code
• The ASCII code is 10.
• Used by Unix and other OSes like it or based around it, like Linux and modern macOS.

2. CR (CARRIAGE RETURN)

• stands for CARRIAGE RETURN
• denoted with \r
• puts the cursor on the beginning of a line.
• The ASCII code is 13.
• Used by old versions of macOS before Mac OS X.

3. CRLF (CARRIAGE RETURN AND LINE FEED)

• stands for CARRIAGE RETURN and LINE FEED
• denoted with \r\n
• creates a new line and puts the cursor at the beginning of that new line.
• The ASCII code is 10 for LF and 13 for CR.
• Primarily used on Windows OS.

Git uses LF by default. So when we use Git on Windows, it throws a warning like- "CRLF will be replaced by LF" and automatically converts all CRLF into LF, so that code becomes compatible.

NB: Don't worry...see this less as a warning and more as a notification message.

Butene

What do you mean by "puts the cursnew line beginning" (seems incomprehensible)? Please respond by editing (changing) your answer, not here in comments (without "Edit:", "Update:", or similar - the answer should appear as if it was written today). – Fireproof

Answer 24

On windows, I was getting this warning because my files names were too long. After renaming my files to something shorter (and restarting my editor, VS Code), the error went away.

Jalousie

Answer 25

You can easily solve by creating a file called .gitattributes putting inside:

*.sh text eol=lf

where "sh" is the extension of each file requires LF instead of CRLF. I suppose is sh i your case

Arraign

Answer 26

I had the same issue, and doing git add . && git reset reverted all line endings correctly.

Lechner