Re: [PATCH 2/2] commit: fix ending newline for template files

[Junio C Hamano <gitster@pobox.com>]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Thu, May 28, 2015 at 2:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>
>>> Moreover, it lacks justification and explanation of why you consider
>>> the cleanup unnecessary. History [1] indicates that its application to
>>> -F but not -t was intentional.
>>>
>>> [1]: bc92377 (commit: fix ending newline for template files, 2015-05-26)
>>
>> Sorry, but the date of that commit seems to be too new to be
>> considered "history"; I do not seem to have it, either.
>
> Indeed, I somehow botched that. I meant: 8b1ae67 (Do not strip empty
> lines / trailing spaces from a commit message template, 2011-05-08)

Yeah, that was what I had in mind when I read your response.  And
that one is pretty strong in its own opinion on the "issue" that was
brought up by [PATCH 1/2] being discussed, which was:

    git-commit with -t or -F -e uses content of user-supplied file as
    initial value for commit msg in editor. There is no guarantee, that this
    file ends with newline ...

The log message of 8b1ae67 argues:

    Templates should be just that: A form that the user fills out, and forms
    have blanks. If people are attached to not having extra whitespace in the
    editor, they can simply clean up their templates.

in other words, "if your template ends with an incomplete line and
it causes you trouble, then do not do that!".

As a general principle I am OK with that.

By default, we should run clean-up after the editor we spawned gives
us the edited result.  Not adding one more LF after the template
when it already ends with LF would not hurt, but an extra blank
after the template material does not hurt, either, so I am honestly
indifferent.  If the user specified with the --cleanup option not to
clean-up the result coming back from the editor, then the commented
material needs to be removed in the editor by the user *anyway*, so
one more LF would not make that much of a difference in that case,
either.

So...