The comment states // Determines what character(s) are used to terminate each line in new files. // Valid values are ‘system’ (whatever the OS uses), ‘windows’ (CRLF) and // ‘unix’ (LF only). You are setting “default_line_ending”: “LF”, You should set “default_line_ending”: “unix”,
In git-config, set core.autocrlf to true to make git automatically convert line endings correctly for your platform, e.g. run this command for a global setting: git config –global core.autocrlf true
You can turn off the warning with git config –global core.safecrlf false (This will only turn off the warning, not the function itself.)
dos2unix does that for you. Fairly straight forward process. dos2unix filename Thanks to toolbear, here is a one-liner that recursively replaces line endings and properly handles whitespace, quotes, and shell meta chars. find . -type f -exec dos2unix {} \; If you’re using dos2unix 6.0 binary files will be ignored.
What that usually means is that you have lines ending with something other than a carriage return/line feed pair. It often happens when you copy and paste from a web page into the code editor. Normalizing the line endings is just making sure that all of the line ending characters are consistent. It prevents one … Read more
Ruby does have a method for this: File.readlines(‘foo’).each do |line| puts(line) end http://ruby-doc.org/core-1.9.3/IO.html#method-c-readlines
Check if you have the linebreak-style rule configure as below either in your .eslintrc or in source code: /*eslint linebreak-style: [“error”, “unix”]*/ Since you’re working on Windows, you may want to use this rule instead: /*eslint linebreak-style: [“error”, “windows”]*/ Refer to the documentation of linebreak-style: When developing with a lot of people all having different … Read more
The easiest way to fix this is to make one commit that fixes all the line endings. Assuming that you don’t have any modified files, then you can do this as follows. # From the root of your repository remove everything from the index git rm –cached -r . # Change the autocrlf setting of … Read more
They’re different characters. \r is carriage return, and \n is line feed. On “old” printers, \r sent the print head back to the start of the line, and \n advanced the paper by one line. Both were therefore necessary to start printing on the next line. Obviously that’s somewhat irrelevant now, although depending on the … Read more
The only specific reasons to set autocrlf to true are: avoid git status showing all your files as modified because of the automatic EOL conversion done when cloning a Unix-based EOL Git repo to a Windows one (see issue 83 for instance) and your coding tools somehow depends on a native EOL style being present … Read more