On Thu, 2017-07-13 at 12:23 -0700, Junio C Hamano wrote:
> All good points; if it bothers you that "commit" and "merge" define
> "emptyness" of the buffer differently too much, I think you could
> persuade me to unify them to "the buffer _must_ contain no bytes",
> i.e. not special-casing sign-off lines only "commit".
>
Intereseting, let me give it a try.
To persuade you with this, I have to convince you that the current
behaviour (special-casing of sign-off lines) is defective and/or
biased. It really is for quite a few reasons,
* Though it's not apparent, it indirectly seems to be hindering
(to some extent) the idea of including the sign-off (or) other
trailers which *can't be modified* by the user.
IOW, the current behaviour seems make the contributors/users
falsely believe (at least to some extent) that git *does* have
trailers for commit messages and thus preventing them from coming
up with ideas that could make "untouchable trailers" a reality.
Thus, consider "the buffer _must_ contain no bytes" hoping this
would initiate a "Butterfly effect" :)
* Looking from an implementation perspective, it's biased in that
it checks only for sign-offs. Making it work in general is
difficult as there's no standard definition for the term
<trailer>. That's because it varies with respect to usage, I
think. Different people/projects may consider different lines to
be trailer lines. A few examples are,
* Bug:
* Fixes:
* Change-id:
* Helped-by:
Moreover, some people may wish to have commit messages that only
have such trailers (e.g. "Fixes:"). So, it's difficult to do a
generalized implementation that aborts when the message is empty
or consists only of trailers.
Thus, consider "the buffer _must_ contain no bytes" because it's
not easy to define what a <trailer> means and special casing
"sign-off" is biased.
* 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.
Thus, I conclude that the considering a commit message consisting only
of <trailer>s as empty isn't a good idea and should be dropped.
--
Kaartic
