Git trailing blank lines feature configuration

Git trailing blank lines feature configuration

[Thomas Nemeth]

    Hi !

    I have the habit to keep 1 blank line at the end of my files. To me,
    it eases the EOF modifications (selecting code blocks, pasting them)
    in vim.

    Note that I still want to remove blanks at EOL. But I'd like to keep
    1 blank trailing line. I still can, of course, but the diff still
    shows me a red "+"...

    Would it be possible to have a configuration option to avoid warnings
    (because I see that as a warning) about trailing blank lines ?

    Thanks

Thomas.

Re: Git trailing blank lines feature configuration

[Johannes Sixt]

Am 31.07.26 um 12:19 schrieb Thomas Nemeth:
>     I have the habit to keep 1 blank line at the end of my files. To me,
>     it eases the EOF modifications (selecting code blocks, pasting them)
>     in vim.

(Call this is [x].)

>     Would it be possible to have a configuration option to avoid warnings
>     (because I see that as a warning) about trailing blank lines ?
Hearing the first time that an extra blank line at EOF is necessary or
useful. Would the correct question then perhaps be: how do you all
handle [x] without an extra blank line at EOF?

That said, are you looking to disable blank-at-eof from core.whitespace?
Collect all "enabled by default" except this one from [*].

[*]
https://git-scm.com/docs/git-config#Documentation/git-config.txt-corewhitespace

-- Hannes

Re: Git trailing blank lines feature configuration

[Thomas Nemeth]

Le vendredi 31 juillet 2026, 13:08 Johannes Sixt a écrit :
> Am 31.07.26 um 12:19 schrieb Thomas Nemeth:
> >     I have the habit to keep 1 blank line at the end of my files. To
> >     me,
> >     it eases the EOF modifications (selecting code blocks, pasting
> >     them)
> >     in vim.
> 
> (Call this is [x].)
> 
> >     Would it be possible to have a configuration option to avoid
> >     warnings
> >     (because I see that as a warning) about trailing blank lines ?
> 
> Hearing the first time that an extra blank line at EOF is necessary or
> useful. Would the correct question then perhaps be: how do you all

    I wouldn't say necessary, of course. It's -- at least -- my
    preference. For _my_ use case, it's useful. When I move code
    around, and that code is at the end of the file or to be put
    at the end of the file, I find it easier to already have a
    blank line there. That is... Because that's how I use vim to
    code.


> handle [x] without an extra blank line at EOF?
> 
> That said, are you looking to disable blank-at-eof from core.whitespace?
> Collect all "enabled by default" except this one from [*].
> 
> [*]
> https://git-scm.com/docs/git-config#Documentation/git-config.txt-corewhi
> tespace

    -_-;
    indeed.

    ```
    git config --global core.whitespace "-blank-at-eof"
    ```

-- 
Thomas.

Re: Git trailing blank lines feature configuration

[Junio C Hamano]

Thomas Nemeth <tnemeth@free.fr> writes:

>     Hi !
>
>     I have the habit to keep 1 blank line at the end of my files. To me,
>     it eases the EOF modifications (selecting code blocks, pasting them)
>     in vim.
>
>     Note that I still want to remove blanks at EOL. But I'd like to keep
>     1 blank trailing line. I still can, of course, but the diff still
>     shows me a red "+"...
>
>     Would it be possible to have a configuration option to avoid warnings
>     (because I see that as a warning) about trailing blank lines ?
>
>     Thanks
>
> Thomas.

Would it be possible with the current system?  No.

Would it be possible to add such a new feature?  If designed well,
perhaps.

Things to consider (though not exhaustive) include:

 - What mechanism should this modify?

 - What should the new option be called?

 - Do we only need to accommodate those who want one trailing blank
   line?  What about those who want two?  Three?

Thanks.

Re: Git trailing blank lines feature configuration

[Junio C Hamano]

Johannes Sixt <j6t@kdbg.org> writes:

> Am 31.07.26 um 12:19 schrieb Thomas Nemeth:
>>     I have the habit to keep 1 blank line at the end of my files. To me,
>>     it eases the EOF modifications (selecting code blocks, pasting them)
>>     in vim.
>
> (Call this is [x].)
>
>>     Would it be possible to have a configuration option to avoid warnings
>>     (because I see that as a warning) about trailing blank lines ?
> Hearing the first time that an extra blank line at EOF is necessary or
> useful. Would the correct question then perhaps be: how do you all
> handle [x] without an extra blank line at EOF?
>
> That said, are you looking to disable blank-at-eof from core.whitespace?
> Collect all "enabled by default" except this one from [*].
>
> [*]
> https://git-scm.com/docs/git-config#Documentation/git-config.txt-corewhitespace
>
> -- Hannes

Ah, if "I want a configuration that does not complain when it sees
any number (including zero) of blank lines" is what is asked for,
then yes, 'blank-at-eof' would be sufficient.  

I misread the request as "I want it to complain if there is not
exactly one blank line at the end" (i.e., zero blank lines will be
flagged as not vi-friendly and two or more blank lines will be
flagged as excess blank lines at the end).  That is not something
'blank-at-eof' would help you achieve.

Re: Git trailing blank lines feature configuration

[Ben Knoble]

> Le 31 juil. 2026 à 20:55, Thomas Nemeth <tnemeth@free.fr> a écrit :
> 
> Le vendredi 31 juillet 2026, 13:08 Johannes Sixt a écrit :
>>> Am 31.07.26 um 12:19 schrieb Thomas Nemeth:
>>>    I have the habit to keep 1 blank line at the end of my files. To
>>>    me,
>>>    it eases the EOF modifications (selecting code blocks, pasting
>>>    them)
>>>    in vim.
>> 
>> (Call this is [x].)
>> 
>>>    Would it be possible to have a configuration option to avoid
>>>    warnings
>>>    (because I see that as a warning) about trailing blank lines ?
>> 
>> Hearing the first time that an extra blank line at EOF is necessary or
>> useful. Would the correct question then perhaps be: how do you all
> 
>    I wouldn't say necessary, of course. It's -- at least -- my
>    preference. For _my_ use case, it's useful. When I move code
>    around, and that code is at the end of the file or to be put
>    at the end of the file, I find it easier to already have a
>    blank line there. That is... Because that's how I use vim to
>    code.

I use Vim, too, and I’ve not personally encountered the desire for keeping a blank line at EOF (though occasionally certain operations benefit from placing one there first!).

I wonder if you could describe example workflows that lead to this desire? I might learn something, and in exchange, if I see a way to accomplish the same thing with less hassle, I’ll suggest it ;)

Cheers

Re: Git trailing blank lines feature configuration

[Thomas Nemeth]

Le vendredi 31 juillet 2026, 20:49 Junio C Hamano a écrit :
> Johannes Sixt <j6t@kdbg.org> writes:
[...]
> >>     Would it be possible to have a configuration option to avoid
> >>     warnings
> >>     (because I see that as a warning) about trailing blank lines ?
[...]
> > That said, are you looking to disable blank-at-eof from
> > core.whitespace? Collect all "enabled by default" except this one
> > from [*].
> 
> Ah, if "I want a configuration that does not complain when it sees
> any number (including zero) of blank lines" is what is asked for,
> then yes, 'blank-at-eof' would be sufficient.

    \o/

    Thanks to you all :)

-- 
Thomas.

Re: Git trailing blank lines feature configuration

[Thomas Nemeth]

Le samedi 1 août 2026, 02:05 Ben Knoble a écrit :
> > Le 31 juil. 2026 à 20:55, Thomas Nemeth <tnemeth@free.fr> a écrit :
> > 
> >    I wouldn't say necessary, of course. It's -- at least -- my
> >    preference. For _my_ use case, it's useful. When I move code
> >    around, and that code is at the end of the file or to be put
> >    at the end of the file, I find it easier to already have a
> >    blank line there. That is... Because that's how I use vim to
> >    code.
> 
> I use Vim, too, and I’ve not personally encountered the desire for
> keeping a blank line at EOF (though occasionally certain operations
> benefit from placing one there first!).
> 
> I wonder if you could describe example workflows that lead to this
> desire? I might learn something, and in exchange, if I see a way to
> accomplish the same thing with less hassle, I’ll suggest it ;)

    It's hard to describe something like that :)

    Imagine you are editing a C file. It contains functions, code blocks
    an so on. I usually organize my code as such :

#includes
[...]
#defines
[...]
static variables
[...]
static functions()
[...]
public_functions()
[...]


    Code reorganization happens quite some times during the development
    process.
    If I need to move a previously static function at the end of the
    public functions section, I switch to VISUAL, select the function
    to be moved with the blank lines above (I like having neatly spaced
    code) _and_ including the eol of the function last line.
    Then I delete it (d), I move to EOF (:$). As the line is blank I
    just have to paste (p) it back there. The function is moved. The last
    blank line is kept for other code movements.

    Conversely, I can select the last function to move it upper in the
    file.

    Adding new functions is also eased. It may be because I use only a
    few vim commands (especially I rarely use the `o` command). But also
    because I like spaced code :)


-- 
Thomas.

Re: Git trailing blank lines feature configuration

[Johannes Sixt]

Am 01.08.26 um 10:48 schrieb Thomas Nemeth:
>     If I need to move a previously static function at the end of the
>     public functions section, I switch to VISUAL, select the function
>     to be moved with the blank lines above (I like having neatly spaced
>     code) _and_ including the eol of the function last line.
>     Then I delete it (d), I move to EOF (:$). As the line is blank I
>     just have to paste (p) it back there. The function is moved. The last
>     blank line is kept for other code movements.

Sounds like you are using character-wise visual mode (v) instead of
line-wise mode (V). Use line-wise operations, and these problems are gone.

Oh, and BTW, just use G instead of :$<Enter>

-- Hannes