25

So I run git diff --check before add-ing files and commit-ing them, and on two specific files I get path/filename:linenumber: new blank line at EOF. If I delete the last empty line in those files, I don't get any messages, but I think it is good style to end my files with a newline. Strangely enough, the other files which I think have exactly the same endings, don't give any messages. I am new to git, using git 2.0.1 on OS X Yosemite. I use vim as my editor.

How can I have my files end with newline while avoiding this message? Should I ignore it?

Improve this question

2 Answers 2

Reset to default
32

There are two issues, here.

  • you are confused about "newline" vs "new line":

    A "new line" is an actual empty line (contains only a "newline" character) and a "newline" is a special character used to mark the end of the current line.

    Most compilers, interpreters and Unix tools expect your text files to end with a newline to avoid ambiguity when dealing with multiple files, not a "new line".

    Most editors, Vim included, add that necessary character at the end of every line, last line included, so there's nothing to do on your side to ensure that requirement is met.

    Especially not adding a "new line" at the EOF.

  • you are probably used to bad behavior:

    The "newline" character is traditionally interpreted as a "line terminator" by Unix tools, most compilers and Vim. This means that whatever comes after that character is considered to be on another line. Since that character is the last one in the file, there's no reason to show a line that is not there to the user.

    Alas, most GUI editors interpret it as a "line separator", meaning that it marks the separation between two lines and those editors usually show a non-existing line at the end of your file to satisfy that interpretation.

    I'm probably assuming too much, but it looks like you are used to that wrong behavior and try to mimic it by adding a totally unnecessary "new line" at the end of your files.

Either you keep adding "new lines" at the bottom of your source files, consider that as some sort of formatting and coding guideline and stop considering those Git messages as error messages.

Or you stop adding those useless "new lines".

I would go with the second option.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

What’s the difference on binary level? For me both “new line” and “newline” look like “}\n”
"On a binary level", a newline character is a \n (or \r on old macs, or \r\n on windows) and a new line is an empty line, with no other character than a newline character, essentially a sequence of two newline characters. But most text editors and text processing tools can be configured to put a newline character at the end of the last line or not and some of them default to not do that. Since most unix-ish systems and tools like Git expect text files and streams to end with a newline character it is best to set up your text editor to add that newline character.
20

From the git diff documentation:

--check

Warn if changes introduce whitespace errors. What are considered whitespace errors is controlled by core.whitespace configuration. By default, trailing whitespaces (including lines that solely consist of whitespaces) and a space character that is immediately followed by a tab character inside the initial indent of the line are considered whitespace errors. Exits with non-zero status if problems are found. Not compatible with --exit-code.

Correspondingly, the git config documentation:

core.whitespace

A comma separated list of common whitespace problems to notice. git diff will use color.diff.whitespace to highlight them, and git apply --whitespace=error will consider them as errors. You can prefix - to disable any of them (e.g. -trailing-space):

  • blank-at-eol treats trailing whitespaces at the end of the line as an error (enabled by default).

  • space-before-tab treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default).

  • indent-with-non-tab treats a line that is indented with space characters instead of the equivalent tabs as an error (not enabled by default).

  • tab-in-indent treats a tab character in the initial indent part of the line as an error (not enabled by default).

  • blank-at-eof treats blank lines added at the end of file as an error (enabled by default).

  • trailing-space is a short-hand to cover both blank-at-eol and blank-at-eof.

  • cr-at-eol treats a carriage-return at the end of line as part of the line terminator, i.e. with it, trailing-space does not trigger if the character before such a carriage-return is not a whitespace (not enabled by default).

  • tabwidth=<n> tells how many character positions a tab occupies; this is relevant for indent-with-non-tab and when Git fixes tab-in-indent errors. The default tab width is 8. Allowed values are 1 to 63.

As you can see, blank-at-eof is enabled by default. You can disable it by adding -blank-at-eof to the core.whitespace configuration, or alternatively by using your own core.whitespace configuration.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.