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

[Jeff King <peff@peff.net>]

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