Subject: RE: Make commit messages optional

From: <[email-masked]>
Date: Sun, 10 Apr 2022 11:00:09 -0400

On April 10, 2022 10:00 AM, Tao Klerks wrote:
>To: Michal Suchánek <[email-masked]>
>Cc: [email-masked]; brian m. carlson <[email-masked]>;
>[email-masked]; [email-masked]
>Subject: Re: Make commit messages optional
>
>On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <[email-masked]> wrote:
>>
>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, [email-masked] wrote:
>> > On April 8, 2022 6:30 PM, brian m. carlson wrote:
>> > >On 2022-04-08 at 03:35:04, [email-masked] 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.
--Randall