line-endings

PhpStorm + GIT line endings changing from LF to CRLF

冷暖自知 提交于 2019-12-06 00:38:28
问题 I have set in my PhpStorm line endings to LF but when I commit to github, sometimes I see some of the files again appear with CRLF line ending (I work on Windows). It happens with the same files I've edited and nobody edited them between my commits/pushes to repository. It's very irritating and I need to often change line endings to the same file. What could it be and how to fix it? I also have checked option "Warn if CRLF line separators are about to be commited" EDIT My local git config is

SVN Line ending Style

自古美人都是妖i 提交于 2019-12-05 23:56:14
问题 When i try to commit the file in SVN its showing error as "Commit failed".Details follow....commit svn: Inconsistent line ending style. 回答1: Check your svn properties on the directory / files. If you have svn:eol-style defined, but your file contains different styles (Unix vs DOS) the commit will fail, since SVN doesn't know which to convert to. Reference: http://svn.haxx.se/users/archive-2006-07/0702.shtml 回答2: Once you're aware of the line ending style svn expects, most modern editors will

Universal newline support in Ruby that includes \r (CR) line endings

♀尐吖头ヾ 提交于 2019-12-05 20:19:07
问题 In a Rails app, I'm accepting and parsing CSV files that may come formatted with any of three possible line termination characters: \n ( LF ), \r\n ( CR+LF ), or \r ( CR ). Ruby's File and CSV libraries seem to handle the first two cases just fine, but the last case ("Mac classic" \r line endings) isn't handled as a newline. It's important to be able to accept this format as well as the others, since Microsoft Excel for Mac (running on OS X) seems to use it when exporting to "Comma Separated

git ignore line endings

被刻印的时光 ゝ 提交于 2019-12-05 12:43:19
I know that similar questions have been asked, but I still can't get it working. My project is shared among people using different operating systems, and I'm on OSX. Also, not everyone uses git yet and I end up sometimes having to commit changes of others. Sometimes, out of nowhere git says there are pending changes. Looking at the files they look identical: @@ -1,6 +1,6 @@ -<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment" - xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" -> - <Deployment.Parts> - </Deployment.Parts> -</Deployment> +<Deployment xmlns="http:/

Enforce LF line endings with CsvHelper

删除回忆录丶 提交于 2019-12-05 07:10:49
If I have some LF converted (using N++) CSV files, everytime I write data to them using JoshClose's CsvHelper the line endings are back to CRLF. Since I'm having problems with CLRF ROWTERMINATORS in SQL Server, I whish to keep my line endings like the initital status of the file. Couldn't find it in the culture settings, I compile my own version of the library. How to proceed? From what I can tell, the line terminator isn't controlled by CvsHelper. I've gotten it to work by adjusting the File writer I pass to CsvWriter. TextWriter tw = File.CreateText(filepathname); tw.NewLine = "\n";

^M characters in git commit message (git commit -v)

核能气质少年 提交于 2019-12-05 04:22:15
I am having a weird problem where lots of ^M characters show up in my git commit message. Please find a screenshot attached. This is not causing any problems, just makes it annoying to read through. Tips appreciated. Lazy Badger "The Proper Way", if you use Git in cross-platform environment, contrary to Abhijeet's answer, is: Learn and CORRECTLY configure core.autocrlf settings in each client Read local topic "Why should I use core.autocrlf=true in Git?" as good starting point Thats a windows newline. Newlines in and windows & linux are different. You can remove it using dos2unix. Various ways

Is there an equivalent of BufferedReader.readLine() that lets me pick what my end of line characters are?

六月ゝ 毕业季﹏ 提交于 2019-12-05 01:01:13
The Javadoc for BufferedReader.readLine() says: A line is considered to be terminated by any one of a line feed ('\n'), a carriage return ('\r'), or a carriage return followed immediately by a linefeed. I need slightly better control than this (e.g. I would like to be able to specify that an end of line is "\r\n", so that an "\n" by itself does not terminate the line). Is there any JDK or library function which does this? Greg Noe Try using the Scanner class: String line = Scanner(file).useDelimiter("\r\n").next(); Depending on what the use case for which you need the BufferedReader, you can

Preserve end-of-line style when working with files in python

廉价感情. 提交于 2019-12-05 00:41:18
I am looking for a way to ensure that the end-of-line style of a file is maintained in python program while reading, editing and writing. Python has universal file ending support, which can convert all line endings to \n when the file is read, and then convert them all to the system default when the file is written. In my case I would like to still do the initial conversion, but then write the file with the original EOL style rather than the system default. Is there a standard way to do this kind of thing? If not, is there a standard way to detect the EOL style of a file? Assuming that there

Normalizing line endings in Visual Studio 2010

余生长醉 提交于 2019-12-05 00:02:00
We have multiple developers working on an application and it seems that whenever one particular person works on a file then anyone else works on it they will get: The line endings in the following file are not consistent. Do you want to normalize the line endings? Is there some option in Visual Studio that we can have that developer change so we don't continually have this very irritating message pop up all the time? If you don't want Visual Studio to check this when it opens the file, you can uncheck the box when prompted ("Always show this dialog") or in Tools->Options under Environment-

git line endings : renormalize does not seem to checkout the right line endings

允我心安 提交于 2019-12-04 22:58:30
问题 I decided to set my line endings the Right Way via a .gitattributes file as detailed for instance here - so I set the core.autocrlf to false and created and committed a .gitattributes file : *.java text eol=native *.jsp text eol=native *.css text eol=native *.html text eol=native *.js text eol=native *.xml text eol=native *.sql text eol=native *.MF text eol=native # git files *.gitignore text eol=native *.gitattributes text eol=native #eclipse files *.classpath text eol=native *.project text