Don't just summarize the content though, summarize the rationale or how things connect. I can read your diff myself to see what changed, I want to know the logical connections, the reason you did X and not Y, etc.

Or just say "stuff" and provide that context in the PR description separately, no need to overdo the commit log on a feature branch if you're using squash merges from your PR.

[–] deadbeef79000@lemmy.nz 8 points 11 months ago* (last edited 11 months ago) (1 children)

P1000x this.

I can read a diff.

I need to know why.

No, a code comment isn't good enough, it's out of date after the next commit.

[–] KeepFlying@lemmy.world 0 points 11 months ago (1 children)

Code comments for "why"s that persist. Commits for why's that are temporary.

If you need to run X before Y, add a comment. If you added X before why because it was easier, leave it in a commit

[–] deadbeef79000@lemmy.nz 1 points 11 months ago

If you need to run X before Y...

Add a test that asserts that.