All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.