On April 10, 2022 11:00 AM, I wrote: >On April 10, 2022 10:00 AM, Tao Klerks wrote: >>To: Michal Suchánek <msuchanek@xxxxxxx> >>Cc: rsbecker@xxxxxxxxxxxxx; brian m. carlson >><sandals@xxxxxxxxxxxxxxxxxxxx>; jurgen_gjoncari@xxxxxxxxxx; >>git@xxxxxxxxxxxxxxx >>Subject: Re: Make commit messages optional >> >>On Sat, Apr 9, 2022 at 1:32 PM Michal Suchánek <msuchanek@xxxxxxx> wrote: >>> >>> On Fri, Apr 08, 2022 at 07:32:03PM -0400, rsbecker@xxxxxxxxxxxxx wrote: >>> > On April 8, 2022 6:30 PM, brian m. carlson wrote: >>> > >On 2022-04-08 at 03:35:04, jurgen_gjoncari@xxxxxxxxxx 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?
