[swanson]

That's fine. I think your opinion is the majority opinion (at least online). It just does not match my own experiences of reality.

You can and should value practices based on your context. But I will be the asshole and ask if writing good commit messages is "so, so, so important" -- what things are less important? Is it more important than a good test suite? Well factored code? System documentation? Capacity for senior staff to answer questions? These things cannot all be so important and, in my experience, worrying about crafting amazing commit messages is way down the hierarchy.

[realbarack]

I'd certainly rather jump into a codebase with a great test suite and crappy commit messages than a crappy test suite and great commit messages. But these are apples and oranges. Keeping a great test suite is a constant fight against tech debt, and testing things properly can be harder than the actual implementation.

In contrast leveling up from the terrible "WIP WIP do the thing" to something slightly less awful takes maybe an extra 1-2 minutes per commit. And every time you do it you're doing your future self and future co-workers a huge favor.

[lowercased]

There's a trend towards automation built around 'commits' that encourages this sort of thing.

"WRITE BETTER MESSAGES".

but put WIP in the title so we know not to review it.

but ... do commit often, so we can get builds out. put WIP in the title so we can decide to build with tests or not. or something.

Tying automation steps to 'commit messages' is begging for "WIP JUST COMMITTING TO GET A BUILD OUT" messages, which people then complain about.

[majormajor]

You're starting to contradict yourself a bit, I think.

Will I disagree that good test suites or well factored code or systems docs are more important than commit messages? No.

However... most projects do not have those things and most developers on those projects are in a "I don't know what I'm missing" sorta state where they don't bother adding them. Exactly like you point out for good commit messages.

So if 95% of projects have inconsistent and incomplete test suites, never-refactored spaghetti code, and almost no system docs, that doesn't mean we should tell people not to try to do those things. In the same way that the existence of poor commit messages doesn't mean we shouldn't try harder.

The nice thing about commit messages, being a small and simple thing, is that it would be much easier for someone to learn how to write good commit messages overnight than to learn how to write a good test suite, or to refactor their code.

[swanson]

It's commendable to strive to improve. I agree that 95% of projects are a mess. I don't think there is value in writing good commit messages in those environments, even if it is easy. If you're going to spend 30 minutes writing a super awesome commit message, I'd rather you spend those 30 minutes on improving the code or the test suite or even writing the awesome commit message in the JIRA ticket.

If you've reached the point when the next "optimization" you can do is to work on your commit messages, that is awesome.

[majormajor]

I'm picturing 1 to 2 minutes on the message, which is why I don't see it as competing with refactoring or test time.

I also think spending paragraphs on "commit message standards" is overkill. I don't care about full stops or capitalization or anything, I just want to know some basics: "What is this fixing or adding. Why is it done this way. Are there any special considerations that kept it from being done a different way?"

You bring up a good point about location, too; i don't particularly care if the info is in a ticket or commit message or a pull request, as long as I can get to it)

[idolaspecus]

I think they can in fact all be "so, so, important". Maintaining a large, long-living, complicated codebase is a genuinely difficult problem involving a plethora of actually critical components and processes.