As time passes, practically no actively maintained codebase is going to clear your bar. It's going to pass through several different teams, with different policies and standards. Eventually, parts of it are going to be put on life support, which generally means an understaffed team that scrambles to patch up the most egregious bugs, often with dirty hacks, because they have no time and resources to do massive rewrites that are necessary to fix things properly. Maintaining such codebases requires a lot of "code archeology", and good history makes it much, much easier.

Not sure I get your point. People will cut corners and mess up the code, but somehow the history could be excempt from this?

Having properly separated and single-purpose commits is awesome when running `git bisect` [1] — especially with automatic tests. As well when you revert said commits after the offender is found.

[1]: https://git-scm.com/docs/git-bisect

If you're using a CI that runs on every PR/master merge wouldn't it catch this without the need for git-bisect?

Only if your tests have perfect coverage. And by "perfect" I don't mean lines or branches, but program states.

> I don’t understand why the history of the code matters so much to some people.

Having the git blame output of the line I'm changing is very helpful when determining the potential consequences of changing that line. If the history doesn't matter, then why bother with commit messages at all. You could essentially script your editor to run "git commit -a --allow-empty --allow-empty-message" every time you write the files to disk.

Our workflow is: - branch - commit first version, open Github PR with a text describing the PR, which is usually longer than the git commit message and contains links to notion pages and other things detailing the design - reviewers look at the code, and there is some to and fro with smaller commits until the PR is fine - code gets merged

So the main action happens outside of git. Maybe for other workflows git commit messages are more important.

>commented (!) code,

Comments become stale and will often not be updated as the code changes.

This is what code reviews are for. Why would you exclude comments from that? It certainly doesn't happen in our team.

Comments often refer to stuff that's not directly in the "review window" i.e. the actual diff plus additional context you'll see in a typical code review setup.

So even if people are conscientious about reviewing comment changes (and absence thereof!), too this often gets missed.