Re: [PATCH] commit & merge: modularize the empty message validator

[Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>]

On Fri, 2017-07-14 at 23:19 +0530, Kaartic Sivaraam wrote:
>         * Imagine a hypothetical version of git that aborts when the
>         <message> is empty though a <trailer> is present. This would
>         quite possibly instigate controversies as the "hypothetical git"
>         reduces the "valid commit messages" and would quite possibly
>         reject a commit message as "empty" (which is uncommunicative)
>         though a previous version (which did not have this change)
>         accepted a similar message.
> 
>         SO, bringing in the Occam's razor, let's choose the option that's
>         the simplest and makes the fewest assumptions.
I would like to add a little to the "making fewer assumptions" point.
If we make the fewest assumptions possible, it has quite a few
advantages,

* It would make the implementation that checks for an empty message,
trivial. Thus reducing the complexity of the code.

* It would not overload the meaning of the error message,

    Aborting due to empty commit message.

Thus making the sentence stand for what it means "literally". 
(BTW, I guess an "an" is missing in the message)

* It allows for others to have more freedom in defining what a commit
message should have using the appropriate hook(s). IOW, let us do the
minimal check(message consisting only of whitespaces) and let the
others define what a commit message should have using the "commit-msg"
hook.

-- 
Kaartic