This is kind of like me except I list the component, function or class I did the change in. We do a squash on each branch before merging anyway

You're lucky that you have him.

Not really because none of his commits have any context on what the purpose any of his changes are actually for. He never describes why he does anything, just that he is changing something (which is obvious from the code).

It's the git equivalent of "useless comments" like `int x = 10; // set x to 10`

In my opinion, commits aren't a record of why. They are a record of what. Commit messages a shorthand of what for easier skimming.

Comments answer why (and even 'what' is fine if the code is difficult.)

But simple rules like that always have exceptions.

Assuming you squash the PR and view it holistically, what's the issue?

PRs dont' squashed, nothing gets rebased and only merge commits are allowed for anything non-local. It adds noise to trying to figure out why changes are made because the commit messages only explain what was changed, not the purpose or context.

If you're not squashing your PR's I can see the problem, but I also see the other problem.

Do you think squashing the PR is the superior choice? Why?

Because then you don't see all those minor little changes and can view the PR holistically. I don't typically find that viewing the changes in chronologically order buys much, it's not the order I care about, it's the final changes themselves that have an impact on the system, especially when those changes could be transient (changing something in commit #1, change it back in commit #3). There's a larger load to comprehension with a squashed commit, but it shouldn't be THAT large, and it removes all the temporal noise.

It also makes tracing the historical "why" of a change easier to understand. If you don't squash it's a random change in the log, if you do squash then it's "adding feature x".