Thread (6 messages) flat view 6 messages, 2 authors, 2017-08-21

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

From: Kaartic Sivaraam <hidden>
Date: 2017-07-15 08:32:56

Possibly related (same subject, not in this thread)

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help