"Inconsistent line ending style" nightmare

Question

I'm completely stuck with an SVN error when committing 2447 files at once. I'm using TortoiseSVN (latest version) on Windows 7 64 bits.

The fact is that some files were created on Mac, and others on PC, so TortoiseSVN stopped the commit with an annoying Inconsistent line ending style error.

In the beginning, to solve this problem, I manually opened the incriminated file in NetBeans, added one blank space, removed it and saved the file so NetBeans converted properly all line ending characters, but it seems there are more than "some files" incriminated.

Voyageur

I would try using unix2dos on a cygwin shell. – Teary

Write a small program that looks for mac style terminator and replaces them with windows style? Netbeans find&replace with regex might also be able to do that. – Soosoochow

Notepad++ can also find & replace in multiple files at once and supports searching for \r, \n, etc. – Teary

I prefer the @assylias's solution. I created a regex which works almost : \w\n$ - it select all Unix EOL chars, except that it select also the first character (\w) at the beginning... – Voyageur

You can capture the w: (\w)\n$ and replace with $1\r\n where $1 is the character. – Soosoochow

Thank you it worked (after modifying it a bit for my needs) !! – Voyageur

Answer 1

Under Windows 7, you can use Notepad++ v5.6.8 to convert EOL characters:

Menu Edit → EOL Conversion → Windows / Unix / Mac

Raymonderaymonds

Thanks man! After being a while with GIT I had totally forgot about this! – Gopherwood

Answer 2

You can capture the w, (\w)\n$, and replace it with $1\r\n where $1 is the character.

Searching and replacing with NetBeans with this regex does the job.

My problem was that a custom script inserted wrong EOL characters (\n instead of \r\n) in these files).

_{(I answered my own question with @assylias's comment.)}

Voyageur

If this works the best for you, why didn't you marked it as answer? – Pulse

@SimonSobisch: Probably because stackoverflow does not allow you to accept your own answer until 48 hours have passed, and it isn't worth most people's time to remember to go back and accept it once that is possible. – Balsamic

@Balsamic This is unlikely in this case as Epoc did accept an answer that was posted two weeks after his own one. I Just asked because he explicit wrote in his answer "this worked for me" but marked the answer with the most votes as "this worked for me". – Pulse

The most upvoted answer is much more simpler than the mine. – Voyageur

Answer 3

In Notepad++, select menu View → Show Symbol → Show End of Line.

In the search box (Ctrl + F), select the Regular Expression search mode and search for the string:

[^\r]\n$

(translation: \n without a \r before it).

This will bring you directly the problem line(s) where you'll see the line ending with LF rather than with the pair CR-LF.

Tunis

Are you sure the dot after the character group is correct? AFAICS, this regex selects lines that contain anything but a \r followed by anything followed by \n. Shouldn't the expression be [^\r]\n$? – Monteria

Thanks, was not supposed to be there. This form found for me the line that ended with \n rather than the \r\n. Fixed – Tunis

my NP++ matches with $\r\n instead of \r\n$ (counts the end of a line as the char before the line delimiter), just in case anyone's having issues – Morelos

Answer 4

If your line endings are all in order, it could be that your text file has a UTF-16 byte order mark (BOM).

You can fix that using Notepad++. Menu Encoding → Convert to UTF-8.

Apanage

Nice catch! For some reason windows scheduler exports its tasks to xml files of UCS2 LE BOM encoding :| tortoise didn't like that very much, apparently. After going to UTF scheduler was still able to import them back so this works for me – Morelos

Answer 5

I opened the project properties window by right-clicking the file explorer while browsing the repository I wanted to edit, and then selected:

TortoiseSVN → Properties → New... → EOL → As is (no specific EOL) → OK.

Beslobber

Answer 6

In Vim or gVim under Windows, the broken files all showed ^M at the end of each line.

To fix it: :s/\r//g to remove the broken extra line endings.

Monteria

Answer 7

In relation to the post from Fabian Streitel, actually the Vim regular expression should be :1,$s/\r//g to cover the entire file.

Another way on Unix-like systems is using sed:

sed -i '-es/\r//g' <your_file>

Hoofer

Don't refer to an answer as "just above." They are ordered by score, so what's "just above" can change. Also, this should be a comment on that answer, not a separate answer, if it's just a correction. You should clarify your answer, and either make it standalone or delete it. – Papaya

Related (currently at 41 reputation points): Why do I need 50 reputation to comment? What can I do instead? – Calender

Answer 8

To solve the problem with different line endings, you can set the Subversion (SVN) property as follows:

svn propset svn:eol-style native my_file

Although this will solve the line endings problems and make merging easier, it will mean that blame will show the person adding the EOL-style as the changer of all lines, and it also means that your working files will end up getting copied into a temporary folder when doing a diff.

The blame issue can be solved afterwards by doing this:

svn blame my_file -x "--ignore-space-change --ignore-eol-style"

Bots