[AeroNotix]

Essentially zero people read complex commit messages.

Do with this information what you will.

9/10 the code already is documentation enough for what the code currently does, if you need to go back through history then look at the commits. The messages are generally noise.

I've literally never cared _why_ someone made a change, I can see the change, I can see the effect of the old and new code. Rarely, if ever, has the thought process ever changed how I will interact with the code in question.

If I am at the level of debugging or history spelunking that the _commit message_ is the thing that saves me - I've already lost and there are other glaring organizational or design issues that are the actual problem.

[advisedwang]

> Essentially zero people read complex commit messages

I don't think that's true. I worked in support doing break/fix and outage response work at a large organization. That means constantly dipping into codebases I'm utterly unfamiliar with. Often there is complexity, un-obvious elements, previous incorrect attempts at a bugfix and so on, where understanding what the author intended can save literal hours of examination, experimentation etc.

> If I am at the level of debugging or history spelunking that the _commit message_ is the thing that saves me - I've already lost and there are other glaring organizational or design issues that are the actual problem.

This is kind of understanding what I mean, but there was no organizational or design failing here. This is just the nature of some work, I believe.

[AeroNotix]

> [..] where understanding what the author intended can save literal hours of examination, experimentation etc.

The problem with that it that you are relying on an inherently unreliable source of information - a human to enter details which may or may not lead you to the correct path.

The code doesn't "lie". Just read it and the current issue and work from there.

[jotaen]

The code may tell you what it does, but that doesn’t necessarily tell you why it’s there.

Especially for non-obvious pieces of code I have to deal with, I certainly prefer to understand the original reasoning and context within 5 minutes by looking at the original commit / PR, than having to spend multiple hours rediscovering that one quirky edge-case scenario that someone else already dealt with 3 years ago.

[gray_-_wolf]

The code might not lie, but is also does not tell you why the DNS record in your IaC was changed from 1.2.3.4 to 4.3.2.1...

Well written commit messages are useful. Some people use issue tracking system instead, but commit message should have the information in more concentrated form instead of spread over 50+ messages of discussion.

[advisedwang]

Code doesn't lie, but it isn't always obvious either. A diff that fixes a subtle corner case is very difficult to understand without explanation. A function to fix dirty external data cannot be understood without reference to what the author is fixing. It may not be clear why a certain performance trade-off is preferable. A mistake may be hard to detect if you don't know what was intended.

[mnau]

There should be a test along with that edge case then. In same commit that fixed the edge case. Possibly updates to documentation, change log etc.

Commits are a purely for developers, excluding the rest of team.

[kelnos]

> The code doesn't "lie". Just read it

No thanks. Some diffs aren't obvious. I'm not a mind reader. Having extra context is useful.

[kelnos]

Even if it's true that essentially zero people read complex commit messages, that one person who needs to read it, 2 years later, will really appreciate its existence.

To me a commit message isn't there so someone can sit around and read commit messages to tell themselves a story. It's there in the -- hopefully unlikely -- possibility that there's a problem with the change, and someone needs to come back to it later, with no context, and understand why it was made so they can figure out what needs to be done.

I've absolutely used commit messages when debugging, and I don't think there's anything wrong with that.