> Ooookayy. I would not compare any technical decision in this space to that. A bit grandiose. One has to be able to understand an analogy for the point the pe

> Ooookayy. I would not compare any technical decision in this space to that. A bit grandiose. One has to be able to understand an analogy for the point the person is trying to make -- it's not an equivalence. Obviously most software issues don't rise to the level of life or death. That said, let's try a few others: - Waterfall - DCOM - CORBA - Web Services - Microservices (as implemented by web developers -- per-entity web api to web api to web api cascading failure) - Monorepos (not globally, with sufficient support these can work) - Devs shouldn't write tests - Fat Model, Skinny Controller - Write tests. Not too many. Mostly integration. - Single Page Apps for all - SCRUM - Story points Most, if not all of those were embraced by "most experts", but are now demonstrated problematic or at least are knowably wrong from fundamental design principles. Note that statistically speaking, "most experts" are, at best, early majority. There aren't very many in the Innovators and Early Adopters, and crossing that chasm is rare, and hard. We have a history in our community of intransigence, repeating mistakes, and expert beginners being the most outspoken portion of our community. They are the ones that have the most to gain by blogging and self-promotion and there are significantly more of them than people who may have different things to say for good reason. Note that right now, I am speaking generally, not debating a commit message approach. > Then... you disagree with the "of course", you said. No, the "of course" was: of course no one I work with would make that mistake (more than once). It would be an extremely beginner mistake, and we would have failed as coaches on our team to not pair with a person long enough to help them understand how to write proper commit messages. > I'm going to assume that's a dependency version change. Yes, it's a pinned version for that dependency. You don't have any context on that particular commit, so it's not surprising that it's ambiguous. > Most theories are wrong, even by experts. It's not even embarrassing to be wrong. Indeed! I have been wrong many times in my career. Hell, I invented the "auto-mocking container" which, in hind sight was so stupid (and btw, my colleague you referenced warned me about it at the time -- he's always been a few steps ahead) that I never should have popularized it. Thankfully, it fell into the past along with IoC containers (for the most part). I have plenty of other stories about being wrong as well, and as I've said elsewhere, if we find a better way to write commit messages we will do that. For now, from our analysis, the way we do it is best for us -- observably (I'll say that, rather than objectively, though I do believe we were as objective as possible in our analysis). Thanks for the discussion.