On Sun, Apr 10, 2022 at 5:18 PM <rsbecker@xxxxxxxxxxxxx> wrote: > On April 10, 2022 11:00 AM, I wrote: > >On April 10, 2022 10:00 AM, Tao Klerks wrote: > > > >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. I don't understand your point here. Allowing empty commit messages, as well as near-empty commit messages, is already a part of the git ecosystem. Git itself does not, and could never, validate the value/meaningfulness of any commit messages. DevSecOps, corporate compliance, accountability, auditability - these are all useful and necessary concepts, but meeting their requirements is not the business of a client that millions of users use to do their daily work - it is instead the business of secured server environments (that you might want to push to), auditors, software supply chain management software, etc. Obviously your users (the ones that are expected to meet certain requirements) should be discouraged or (more likely) prevented from pushing messageless commits to the branches/environments that carry auditability requirements; I'm guessing they probably also need to have references to other systems (eg ticketing systems) to provide an external "rationale" audit, GPG signature, ACLs and other things that are simply not the business of the client. I agree it would be a mistake to make it easier for such users (or any users, really) to *accidentally* commit something without a message, and then find themselves in a not-always-obvious "now I need to change the past" situation. > > > >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. No amount of "hardening" the client that people run on their own machines will improve the security of *your* applications in any way. All the problems you describe involve *server* security. Whether other people choose to use the client to make toys, or art, or banking software, or git itself... is their business? The implication that the use of git in "serious industries" should make it worse for other users (such as toymakers) is, I believe, unhelpful at best. > > > >>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. Given your earlier comments, I'm not sure I understand the "this" you're not going to be convinced by or about. What I was proposing, and maybe I did a terrible job of it, is to *not* change the behavior of the client in any significant way, but rather add some new advice (which, like any git advice, can be turned off, eg by a corporate git installer), which would show alongside the current "Aborting commit due to empty commit message." error. The exact text of that advice would obviously need to be carefully considered, but I would expect it to say something like "committing without a message is typically a mistake (and might prevent you from pushing to the server later), but if you really want or need to, you can use the --allow-empty-message option". The point of this advice would be to clarify the existence of the "--allow-empty-message" behavior (and reduce the incidence of "stupid" commit messages like single periods), *without* in any way increasing the incidence of *accidental* submission without a commit message. > > 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? > My proposal is that it absolutely is enough, functionally - but the abundance of "we should change something" concerns in this thread and elsewhere suggest, to me, that it might not be sufficiently discoverable; hence the "advice" proposal.
