# Bug in default commit hook (improperly forbidding a single blank line at EOF)

3 messages from 2015-09-08 to 2015-09-08. Participants: Raymond Jennings, Jeff King.
Thread: https://gitlist.dev/t/40298

## Raymond Jennings, 2015-09-08 01:37

Subject: Bug in default commit hook (improperly forbidding a single blank line at EOF)
Message-ID: <55EE3BD9.7020707@gmail.com>
URL: https://gitlist.dev/e/55EE3BD9.7020707%40gmail.com

```
Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further 
details.

Files *should* have a single blank line at the end, because a line 
should always have a newline at the end.

Adding a newline to the end of a file whose last line doesn't have one 
should be legal...as long as you don't create empty lines at the end.

```

## Jeff King, 2015-09-08 04:55

Subject: Re: Bug in default commit hook (improperly forbidding a single blank line at EOF)
Message-ID: <20150908045504.GA26331@sigill.intra.peff.net>
URL: https://gitlist.dev/e/20150908045504.GA26331%40sigill.intra.peff.net
In-Reply-To: <55EE3BD9.7020707@gmail.com>

```
On Mon, Sep 07, 2015 at 06:37:29PM -0700, Raymond Jennings wrote:

> Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further
> details.
> 
> Files *should* have a single blank line at the end, because a line should
> always have a newline at the end.

I'm not sure I follow. Lines should have a newline at the end, but there
is no need to start a _new_ blank line. So a file with zero bytes has no
lines (and no newline).

A file that contains a single line, like "one\n", has each line end in a
newline, and the file ends in a newline. There is no blank line.

A file like "one\n\n" has two lines: one with text, and a blank line at
the end.

Can you clarify (preferably by showing a byte sequence of the file in
question) what file you are feeding to the hook, what output you get,
and what output you expect?

> Adding a newline to the end of a file whose last line doesn't have one
> should be legal...as long as you don't create empty lines at the end.

If you mean turning "foo" (a file with no newline!) into "foo\n", I
agree that is legal, and does not create an empty blank line at the end.
But I don't think the hook complains about that.

E.g., we can create a sequence of file content:

  git init

  echo -n one >file
  git add file
  git commit -m 'no newline'

  echo >>file
  git add file
  git commit -m 'complete line'

  echo >>file
  git add file
  git commit -m 'add a blank line'

and run "log --check", which runs the same code that the pre-commit hook
does:

  git log --check

Git complains only about the final, which looks right to me. If you want
to redefine git's idea of which whitespace is worth complaining about,
try:

  git config core.whitespace -blank-at-eof

See the description of core.whitespace in "git help config" for the
complete list.  You can also set it per-file using gitattributes. See
"git help attributes", section "Checking whitespace errors".

-Peff

```

## Raymond Jennings, 2015-09-08 05:03

Subject: Re: Bug in default commit hook (improperly forbidding a single blank line at EOF)
Message-ID: <55EE6C06.7010403@gmail.com>
URL: https://gitlist.dev/e/55EE6C06.7010403%40gmail.com
In-Reply-To: <20150908045504.GA26331@sigill.intra.peff.net>

```
On 09/07/15 21:55, Jeff King wrote:
> On Mon, Sep 07, 2015 at 06:37:29PM -0700, Raymond Jennings wrote:
>
>> Please see https://bugs.gentoo.org/show_bug.cgi?id=559920 for further
>> details.
>>
>> Files *should* have a single blank line at the end, because a line should
>> always have a newline at the end.
> I'm not sure I follow. Lines should have a newline at the end, but there
> is no need to start a _new_ blank line. So a file with zero bytes has no
> lines (and no newline).
>
> A file that contains a single line, like "one\n", has each line end in a
> newline, and the file ends in a newline. There is no blank line.
>
> A file like "one\n\n" has two lines: one with text, and a blank line at
> the end.
>
> Can you clarify (preferably by showing a byte sequence of the file in
> question) what file you are feeding to the hook, what output you get,
> and what output you expect?
>
>> Adding a newline to the end of a file whose last line doesn't have one
>> should be legal...as long as you don't create empty lines at the end.
> If you mean turning "foo" (a file with no newline!) into "foo\n", I
> agree that is legal, and does not create an empty blank line at the end.
> But I don't think the hook complains about that.
Sorry, my mistake.  I just took a look at the file on console with 
mcedit, and it looks like gedit lied to me.

I'll be contacting gedit's maintainers with this instead, sorry for the 
spam.
> E.g., we can create a sequence of file content:
>
>    git init
>
>    echo -n one >file
>    git add file
>    git commit -m 'no newline'
>
>    echo >>file
>    git add file
>    git commit -m 'complete line'
>
>    echo >>file
>    git add file
>    git commit -m 'add a blank line'
>
> and run "log --check", which runs the same code that the pre-commit hook
> does:
>
>    git log --check
>
> Git complains only about the final, which looks right to me. If you want
> to redefine git's idea of which whitespace is worth complaining about,
> try:
>
>    git config core.whitespace -blank-at-eof
>
> See the description of core.whitespace in "git help config" for the
> complete list.  You can also set it per-file using gitattributes. See
> "git help attributes", section "Checking whitespace errors".
>
> -Peff

```