git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Raymond Jennings <shentino@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Bug in default commit hook (improperly forbidding a single blank line at EOF)
Date: Mon, 7 Sep 2015 22:03:02 -0700	[thread overview]
Message-ID: <55EE6C06.7010403@gmail.com> (raw)
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

      reply	other threads:[~2015-09-08  5:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08  1:37 Bug in default commit hook (improperly forbidding a single blank line at EOF) Raymond Jennings
2015-09-08  4:55 ` Jeff King
2015-09-08  5:03   ` Raymond Jennings [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55EE6C06.7010403@gmail.com \
    --to=shentino@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).