* Bug in default commit hook (improperly forbidding a single blank line at EOF)
@ 2015-09-08 1:37 Raymond Jennings
2015-09-08 4:55 ` Jeff King
0 siblings, 1 reply; 3+ messages in thread
From: Raymond Jennings @ 2015-09-08 1:37 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug in default commit hook (improperly forbidding a single blank line at EOF)
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
0 siblings, 1 reply; 3+ messages in thread
From: Jeff King @ 2015-09-08 4:55 UTC (permalink / raw)
To: Raymond Jennings; +Cc: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Bug in default commit hook (improperly forbidding a single blank line at EOF)
2015-09-08 4:55 ` Jeff King
@ 2015-09-08 5:03 ` Raymond Jennings
0 siblings, 0 replies; 3+ messages in thread
From: Raymond Jennings @ 2015-09-08 5:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-09-08 5:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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.