It really pays the effort back, though, when you can figure out why something was done, beyond knowing the feature it was related to, which is all you get with a squash merge.
But if you're using pull requests, you can just look up the PR to get the reasoning and details of the squash commit. I would argue that if you need it to be separate commits after merging, you should create separate PRs most of the time.
...are you suggesting spending hours searching through documentation, hoping to possibly find something relevant, instead of just being able to run "git blame" to see why a specific line was changed?
Code tells how, not why—the domain of specs and comments. Commit messages effectively don’t exist for non-developers.
I put spec links in doc strings whenever possible. They are accessible to everyone—devs, PMs, SMEs, stakeholders that pay bills, and myself when at a web browser.
Searching is not required but even if it was it would be a tiny fraction of “hours.”
