threads / bug / 40298

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

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

## tl;dr

3 messages between Sep 8, 2015 and Sep 8, 2015.

replies: 2people: 2as markdown or json

Raymond Jennings· Sep 8, 2015, 01:37 UTC · lore

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· Sep 8, 2015, 04:55 UTC · re: Raymond Jennings · lore

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

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

Show 5 quoted lines

> 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· Sep 8, 2015, 05:03 UTC · re: Jeff King · lore

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

On 09/07/15 21:55, Jeff King wrote:

Show 26 quoted lines

> 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.

Show 32 quoted lines

> 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