git replacing LF with CRLF

Question

Running git on a Windows XP machine, using bash. I exported my project from SVN, and then cloned a bare repository.

I then pasted the export into the bare repositories directory, and did a:

git add -A

I then got a list of messages saying:

LF will be replaced by CRLF

What are the ramifications of this conversion? This is a .NET solution in Visual Studio.

@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). — RJFalconer, Dec 28 '09 at 11:42
why would the line endings be different unless the entire line was touched — Bjorn, Dec 31 '09 at 07:48
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). — MatrixFrog, Nov 25 '10 at 17:29
An upstream discussion of the same issue: http://kerneltrap.org/mailarchive/git/2008/4/16/1450834/thread — Tim Abell, Apr 17 '12 at 16:00
@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. — MarcH, Jul 29 '14 at 19:55
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 :--( — Jon Watte, Feb 07 '15 at 07:11
Similar question https://stackoverflow.com/questions/9976986/force-lf-eol-in-git-repo-and-working-copy has more details on how to reset git index and line breaks handling on working copy while preserving files. — Vadzim, Jun 16 '17 at 20:58
Upstream discussion was at kerneltrap; that seems to be gone now. Wayback archive: https://web.archive.org/web/20110805073326/http://kerneltrap.org/mailarchive/git/2008/4/16/1450834/thread — Sean McMillan, Jul 28 '20 at 13:37
Does this issue persist on 2020, ten years after the original question? — carloswm85, Oct 05 '20 at 23:10
Fix is on this page but some pagedowns later https://stackoverflow.com/a/29888735/340142 — Marecky, Dec 06 '20 at 21:37

score 1138 · Answer 1 · edited Jun 20 '20 at 09:12

1138

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

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

Bad news: 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:
                                             
        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

Here crlf = win-style end-of-line marker, lf = unix-style (and mac osx).

(pre-osx cr in 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

Default value for core.autocrlf is selected during git installation and stored in system-wide gitconfig (%ProgramFiles(x86)%\git\etc\gitconfig). 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 dir.

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

   – add autocrlf=false to system-wide gitconfig # 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.

edited Jun 20 '20 at 09:12

Community

1
1

answered Dec 18 '13 at 08:30

Antony Hatchkins

25,545
8
96
98

43

For the amount of time I've spent to get this far, I was hoping for a core.crlf=rackoff ;-) – PandaWood Jan 20 '14 at 23:37
10

I restructured the content, maybe it will be easier to read this way – Antony Hatchkins Jan 21 '14 at 04:34
7

sorry, I hope my comment wasn't taken as a criticism of your answer. By "to get this far" I mean, before finding this answer. – PandaWood Jan 21 '14 at 05:36
3

oh it's ok :) Anyway your comment motivated me to improve my answer. – Antony Hatchkins Jan 22 '14 at 10:45
11

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 – isimmons Jul 15 '14 at 21:48
Did you check the local (per-project) autocrlf? – Antony Hatchkins Jul 17 '14 at 09:58
1

git config core.autocrlf=false gives an error. It should be: git config core.autocrlf false (space instead of '=') – lanierhall Oct 22 '14 at 16:21
22

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? – Hubro Nov 14 '14 at 12:07
1

That's because bizzare errors I can potentially get (eg [Cannot remove worktree changes](http://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git)) 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. – Antony Hatchkins Nov 17 '14 at 05:43
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. – Antony Hatchkins Jan 10 '15 at 20:20
2

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 – digory doo Oct 18 '16 at 08:08
3

Figured it out: .gitattributes can override the config settings. – digory doo Oct 18 '16 at 08:24
1

I agree [with Hubro](http://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf#comment42404705_20653073): 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`. – Henrik Heimbuerger Feb 28 '17 at 13:40
@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. – Antony Hatchkins Feb 28 '17 at 13:50
5

@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? – Henrik Heimbuerger Feb 28 '17 at 22:07
2

@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. – Antony Hatchkins Mar 01 '17 at 05:38
@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. – Antony Hatchkins Mar 01 '17 at 05:41
1

@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. – Henrik Heimbuerger Mar 03 '17 at 21:08
@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. – Antony Hatchkins Mar 04 '17 at 08:42
3

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. – Antony Hatchkins Mar 04 '17 at 08:49
@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. – jpaugh Sep 20 '17 at 20:40
@jpaugh 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` – Antony Hatchkins Sep 21 '17 at 14:02
On Windows Vista or newer the system gitconfig can instead be found at `C:\ProgramData\Git\config` – Lorkenpeist Dec 12 '19 at 03:58
For *explanation* this is a good answer; for *recommendation* it's badly out of date — see why [gitattributes supercedes autocrlf](https://stackoverflow.com/a/59644154/3700414) – Rusi Jan 13 '20 at 12:39
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 – Akhila Dec 07 '20 at 15:05
@Akhila [This SO question](https://stackoverflow.com/questions/48692741/how-to-make-all-line-endings-eols-in-all-files-in-visual-studio-code-unix-lik) deals with configuring VS Code, [this extension](https://marketplace.visualstudio.com/items?itemName=vs-publisher-1448185.keyoti-changeallendoflinesequence) converts line endings in all files – Antony Hatchkins Dec 07 '20 at 15:10
Thanks for that suggestion! @AntonyHatchkins – Akhila Dec 07 '20 at 15:15
1

@Hubro 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. – 12431234123412341234123 Mar 04 '21 at 18:30
My Parser crashed trying to figure out relation between your Moral section and config setting during setup, but don't worry, [git document](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) wasn't any better either. – AaA Mar 30 '21 at 02:13
@Aaa Could you describe your usecase? Are you on windows? – Antony Hatchkins Mar 30 '21 at 09:07
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!" – AaA Mar 31 '21 at 01:34
@AaA 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! – Antony Hatchkins Mar 31 '21 at 07:43
1

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. – AaA Mar 31 '21 at 09:01

score 793 · Answer 2 · edited Apr 19 '17 at 13:22

793

Git has three modes of how it treats line endings:

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

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 repo 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 http://kernel.org/pub/software/scm/git/docs/git-config.html for updated info that includes the "input" value.

edited Apr 19 '17 at 13:22

Melebius

4,692
3
32
43

answered Dec 28 '09 at 04:37

Andrew Arnott

74,820
24
127
163

121

As said here (http://stackoverflow.com/questions/1249932/git-1-6-4-beta-on-windows-msysgit-unix-or-dos-line-termination/1250133#1250133), 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) – VonC Dec 28 '09 at 07:57
23

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? – Krisc Jan 28 '11 at 17:42
13

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. – seh Apr 20 '11 at 00:32
1

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. – Chris Mar 29 '12 at 08:12
@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 – Ehtesh Choudhury May 19 '12 at 04:04
5

For a more permanent solution change your .gitconfig to: [core] autocrlf = false – RBZ Aug 27 '12 at 21:05
git man "This variable can be set to input, in which case no output conversion is performed." – Yasen Sep 13 '12 at 07:30
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. – Yasen Sep 13 '12 at 07:52
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. – neemzy Jun 04 '13 at 13:08
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 ? – Eric MORAND Sep 28 '13 at 22:52
10

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 – UmaN Dec 10 '13 at 08:08
1

To change the setting system-wide: `git config --global core.autocrlf true/false/input` – Gras Double Jul 24 '14 at 16:27
This didn't work for me, but this one does: http://stackoverflow.com/a/18724554/1071486 – aymericbeaumet Sep 14 '15 at 09:01
2

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? – Alex Lomia Dec 09 '15 at 07:15
Linux users can follow VonC's advice by using Kate. `Tools->End Of Line->Unix` – Honest Abe Jul 23 '16 at 17:35
2

@Krisc Late answer, but the way to suppress just the warnings is setting `core.safecrlf` to `false`: http://stackoverflow.com/a/14640908/567000 – Søren Boisen Nov 01 '16 at 10:14
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. – wisbucky Nov 28 '17 at 00:12
@wisbucky 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. – Andrew Arnott Nov 28 '17 at 01:29

score 226 · Answer 3 · edited Mar 05 '20 at 04:01

226

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 re-write git index with

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Note: this is will remove your local changes, consider stashing them before you do this.

edited Mar 05 '20 at 04:01

joeljpa

17
3

answered Apr 27 '15 at 06:33

user2630328

2,341
1
9
10

39

Thank you for a simple, cross-platform, clear way to FIX it, rather than a huge discussion about the config meaning. – Eris Jul 18 '15 at 03:59
3

if git reset --hard is it possible my local change will be lost ? i just follow all comment metion above – Freddy Sidauruk Jan 24 '17 at 10:53
6

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. https://git-scm.com/docs/git-reset – Jacques Apr 04 '17 at 07:20
1

@FreddySidauruk You should double check whenever using the `--hard` or `--force` flags with Git. – JakeD Jun 08 '17 at 00:48
2

What is meaning of `git rm --cached -r .`? Why `git reset --hard` isn't enough? – gavenkoa Aug 07 '17 at 10:27
1

@gavenkoa the `rm` removes all tracked files recursively. You're right that it's probably not needed – Max Nov 09 '17 at 14:26
3

@gavenkoa @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. – wisbucky Nov 27 '17 at 23:56
@user2630328 - 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. – aggieNick02 Feb 07 '19 at 17:06
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 – Jay Sidri Jun 27 '19 at 23:50
1

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? @user2630328 maybe you can elaborate on the difference. – Daniel K. Aug 12 '20 at 06:52
Why did it take so long to find this! Thank you! – Matt Swezey Mar 25 '21 at 02:44
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 – STEEL Mar 30 '21 at 05:31

score 82 · Answer 4 · edited Mar 21 '14 at 05:07

82

git config core.autocrlf false

edited Mar 21 '14 at 05:07

Sahil Mittal

20,351
12
59
88

answered Mar 21 '14 at 04:34

Arun

2,618
21
13

7

make sure to run this inside repository root – Hammad Khan Oct 13 '14 at 06:38
35

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. – Zoran Pavlovic May 22 '17 at 09:12
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 – pixelwiz Aug 11 '17 at 19:54
2

@mbb setting `autcrlf` to `false` just punts the issue to every user of your project. – jpaugh Sep 20 '17 at 20:52
5

@pixelwiz : 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. – Michaël Polla Nov 15 '17 at 17:02

score 49 · Answer 5 · edited Sep 20 '17 at 20:56

49

Both unix2dos and dos2unix is available in windows with gitbash. 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, 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.

edited Sep 20 '17 at 20:56

jpaugh

5,719
4
33
83

answered May 01 '11 at 23:50

Rifat

7,288
4
28
45

1

Here's what the help option says: ` --u2d, -D perform UNIX -> DOS conversion` – Larry Battle Jul 13 '12 at 08:20
@LarryBattle u2d and d2u is not the same thing I believe. – Rifat Jul 13 '12 at 12:38
1

@Rifat 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: http://gopherproxy.meulie.net/sdf.org/0/users/pmyshkin/dos2unix – Larry Battle Jul 13 '12 at 17:10
1

@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. – Rifat Jul 13 '12 at 18:18
@LarryBattle I've deleted my comment because It could mislead people. – Rifat Jul 13 '12 at 18:19
1

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. – Richard Beier Jul 27 '12 at 05:49
This answer could be significantly improved with the information in the comments – mcabral Oct 17 '12 at 17:49
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. – jakub.g Oct 23 '12 at 08:27
I'm using `Windows Bash`, which doesn't seem to support the `-D` or ` --u2d` switch in dos2unix 6.0.4 (2013-12-30) – Andrei Krasutski Nov 13 '19 at 07:56

score 29 · Answer 6 · edited May 23 '17 at 12:34

29

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 (worked for me, anyway).

edited May 23 '17 at 12:34

Community

1
1

answered Jul 19 '14 at 08:10

Yevgeny Simkin

26,055
37
127
228

1

It should be `safecrlf` (with an 'f') – alpipego Jan 19 '16 at 10:19

Gene Pavlovsky · Answer 7 · 2016-10-11T19:41:55.043

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

My personal experience with using the often recommended core.autocrlf config 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 config, 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.

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. — Mike Loux, Jun 15 '18 at 14:04
@MikeLoux Try this method: https://stackoverflow.com/a/44806034/4377192 — Gene Pavlovsky, Jun 17 '18 at 11:50
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" — joeytwiddle, May 14 '19 at 04:34

score 19 · Answer 8 · edited Feb 21 '12 at 11:27

19

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

:set noendofline binary
:wq

edited Feb 21 '12 at 11:27

Zsolt Botykai

46,263
14
81
102

answered Feb 21 '12 at 10:08

Roman Rhrn Nesterov

3,382
1
25
16

2

Simply editing with `vim` would leave all line ending intact. – Eye Dec 06 '12 at 03:22
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. – janineanne May 23 '13 at 22:59

Tim Abell · Answer 9 · 2012-04-17T15:55:19.987

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:

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
Set autocrlf to false, and ignore the fact that the line endings are not in git's preferred style
Check out your files with autocrlf off, fix all the line endings, check everything back in, and turn it back on again.
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.

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 http://stackoverflow.com/a/1060828/64257. — Chris, Mar 29 '12 at 08:45
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. — sleske, Dec 13 '13 at 09:21
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. — Tim Abell, Jan 16 '14 at 15:10
@sleske starting git 2.8, the merge markers will *no longer* introduce mixed line ending. See http://stackoverflow.com/a/35474954/6309 — VonC, Feb 18 '16 at 07:08
@VonC: That's cool. Good to know for the times I need to work on Windows. — sleske, Feb 18 '16 at 08:45

basiloungas · Answer 10 · 2013-01-09T09:49:13.843

13

Removing the below from the ~/.gitattributes file

* text=auto

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

edited Jan 09 '13 at 09:49

answered Jan 09 '13 at 09:36

basiloungas

195
2
7

6

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. – Arafangion Feb 11 '13 at 02:38
1

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). – Matty Sep 01 '15 at 11:40
2

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. – jdunk Dec 27 '16 at 12:13

score 13 · Answer 11 · edited Dec 04 '18 at 11:07

13

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

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 autocrlf option)

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

edited Dec 04 '18 at 11:07

barbsan

3,238
11
18
27

answered Dec 09 '14 at 02:04

Michael Ribbons

1,170
1
12
22

2

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... – MartinTeeVarga Sep 08 '15 at 09:13

score 10 · Answer 12 · edited Jun 20 '20 at 09:12

10

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.

edited Jun 20 '20 at 09:12

Community

1
1

answered Jun 16 '17 at 06:16

Devs love ZenUML

9,490
7
41
55

It also means that what is sent up to Subversion (if you do that) will have the conversion. – jpaugh Sep 20 '17 at 20:35

score 8 · Answer 13 · answered Dec 27 '09 at 23:39

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

Appears to me that git is converting the return format to match that of the running platform (Windows). CRLF is the default return format in 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, JPEGs.

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.

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. — user2548343, Aug 07 '15 at 13:00

score 8 · Answer 14 · answered May 17 '20 at 09:43

Most of tools in Windows accepts only 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, stronlgy recommended! There is no reason to use CRLF in windows!

(The same discussion is using \ in include paths in C/++, it is bullshit, 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.

score 7 · Answer 15 · answered Dec 16 '18 at 03:35

7

Make sure that you have installed the latest git.
I did as above git config core.autocrlf false, when used git (version 2.7.1), but it did not work.
Then it works now when upgrade git (from 2.7.1 to 2.20.1).

answered Dec 16 '18 at 03:35

hyvi tan

71
1
1

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! – Phillip McMullen Feb 21 '19 at 03:05

score 5 · Answer 16 · answered Oct 15 '13 at 11:33

5

Open the file in the Notepad++.
Go to Edit/EOL Conversion.
Click to the Windows Format.
Save the file.

answered Oct 15 '13 at 11:33

1991tama1991

67
1
2

1

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. – Contango Jun 27 '17 at 09:55

score 5 · Answer 17 · answered Mar 31 '15 at 14:39

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:

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

score 3 · Answer 18 · answered Jun 26 '18 at 18:51

3

Many text-editors allow you to change to LF, see Atom instructions below. Simple and explicit.

Click CRLF on bottom right:

Select LF in dropdown on top:

answered Jun 26 '18 at 18:51

JBallin

4,767
33
38

score 3 · Answer 19 · edited Dec 04 '18 at 13:14

3

CRLF could cause some problem while using your "code" in two different OS (Linux and Windows). My python script was written in 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 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.

edited Dec 04 '18 at 13:14

Gihan Saranga Siriwardhana

825
7
25

answered Dec 04 '18 at 10:41

Kshitiz

31
2

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_. – Evan Morrison Jul 14 '20 at 20:44

score 2 · Answer 20 · answered Apr 15 '11 at 06:33

2

In a GNU/Linux shell prompt, dos2unix & unix2dos commands allow you to easely convert/format your files coming from MS Windows

answered Apr 15 '11 at 06:33

Ronan

4,261
3
17
14

git replacing LF with CRLF

20 Answers20

Linked

Related