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

From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Date: Jul 15, 2017, 08:33 UTC
Message-ID: <1500107583.1850.4.camel@gmail.com>
In-Reply-To: <1500054552.18990.8.camel@gmail.com>

On Fri, 2017-07-14 at 23:19 +0530, Kaartic Sivaraam wrote:

Show 10 quoted lines

>         * 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