RE: Make commit messages optional

[<rsbecker@nexbridge.com>]

On April 10, 2022 11:00 AM, I wrote:
>On April 10, 2022 10:00 AM, Tao Klerks wrote:
>>To: Michal Suchánek <msuchanek@suse.de>
>>Cc: rsbecker@nexbridge.com; brian m. carlson
>><sandals@crustytoothpaste.net>; jurgen_gjoncari@icloud.com;
>>git@vger.kernel.org
>>Subject: Re: Make commit messages optional
>>
>>On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@suse.de> wrote:
>>>
>>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@nexbridge.com wrote:
>>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
>>> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@icloud.com wrote:
>>> > >> I think that often commit messages are unnecessary. I propose
>>> > >> that by default a user should be able to commit without a message.
>>[...]
>>> > >We want to encourage good software engineering practices.
>>> > >
>>[...]
>>> > >
>>> > >Users who want this behaviour can use --allow-empty-message or
>>> > >create an alias with that option.  The functionality already
>>> > >exists.  I use aliases extensively in my development and I know
>>> > >others do as well, so this shouldn't be an impediment if you're
>>> > >working on
>>projects where this is acceptable.
>>> > >
>>[...]
>>>
>>> There is nothing stopping you using '.' as the commit message which
>>> is as informative as when it is empty. Hence this enforcement of
>>> non-empty commit message does not serve the stated purpose.
>>
>>My apologies if this proposal has already been made in this or prior
>>discussions - the list server and gmail are having another
>>disagreement, so I think I'm a few hours out of date.
>>
>>I believe the main argument *for* allowing empty commit messages by
>>default is "we shouldn't make it hard to do what you want to do, if you
>>can fix it later", and the main argument *against* is "for most people
>>(non-advanced users), what you do initially is what you end up pushing,
>>or at least trying to push, and fixing things later is *hard*
>>- it requires a much deeper understanding of git than most people
>>otherwise necessarily need to develop".
>
>Adding commit messages has been part of SCM systems since virtually the
>beginning, at least on UNIX in the early 1970 and likely before. Adding a simple
>commit message is not onerous or difficult. "Fixing it later" will require the commit
>and any signature you put on at the time is lost. You also invalidate any signatures
>more recent in history. This does not corrupt your repo, but it does reduce its
>value. If you insist on doing this, use a single non-breaking space symbol in the -m
>option, which you can script or alias. Note that none of that will work on any git
>clients anyway.
>
>The main argument against is that this violates the basic principles of a well
>managed DevSecOps environment that requires who, what, where, when, why
>for every change, not just the ones you publish. The key point here of having
>comments in commits is that it allows organizations to pull in projects like OpenSSL
>that ends up in production and must have the accountability for the installation to
>be allowed. Otherwise, just give up on the concept of Open-Source because
>corporate auditors will reject any request to use your project. You will never get
>into a PCI environment without a full set of commit comments, not just the Pull
>Requests.
>
>Granted my requirements come from regulated industries around the globe, and
>if you are making toys, so be it. My teams are making production-hardened
>applications.
>
>>In that sense, allowing people to create empty commit messages when
>>they shouldn't, is often "trapping" them into a commit history that is
>>less valuable (or even acceptable) than they might otherwise have achieved.
>>
>>While I therefore disagree with Aevar's proposal to "allow empty, and
>>advise", I do think the notion of giving advice makes perfect sense -
>>let's do it the other way around, with an advice message something
>>like:
>>
>>---
>>Empty commit messages aren't normally allowed, as they reduce the
>>understandability of the commit history. If you do need to create a
>>commit with an empty message, you can do so by providing the '--allow-empty-
>message'
>>argument to 'git commit'.
>>---
>>
>>Has this already been considered/discussed? Would it meet the
>>objectives of those folks saying "the rejection of empty messages
>>wasted my time", while also keeping the spirit of "we should make it
>>easy to do the right thing and harder to do the wrong thing, especially for
>beginners"?
>
>I am not personally going to be convinced of any of this - forgive me but, I think
>this reduces git's value and credibility as the leading SCM solution on the planet
>(and off) and see no justification for enabling comment-less repositories other
>than laziness. Even if that were the case, it is grounds for termination in my
>company and most of my customers to deliberately bypass audit practices, so if git
>moves forward with this, we might have to move elsewhere.

And I still don't get why the --allow-empty-message is not sufficient to meet your use case. git supports what is being requested already, not that it is allowed where I am. Are we talking about setting --allow-empty-message as the default? That is a major behavioural change. You could create a git command alias to always specify this option. So what is the point of this?