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