[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.