[WorldMaker]

I don't think you are reading me correctly. That is a rare occurrence, but it is possible when using merge commits to correctly describe the DAG. It's entirely impossible if you overly rebase/squash. Those rare times that I've needed to do it it have "saved" a project a lot of time from a major bug or regression. My normal workflow I look at a "clean" faux linear view, but it's just the "--first-parent" view of merge commits, which gives me a "PR focused" or "integration focused" view of source control first.

[howinteresting]

If your average commit size is 30-40 lines of code, this isn't an issue. Stacks of small commits is a time-tested workflow, used by the Linux kernel among many other projects.

[WorldMaker]

I think we are talking about different things at this point, but I may be losing the thread of your argument here.

I love a code review to consist of lots of small commits. I'm mostly fine if even some of them from developers more junior than me are just named "commit" if they are small.

When I finish the code review I prefer to only `git merge --no-ff`. All those small commits stay in the code history in the exact form they were reviewed under.

If I'm looking at history I'm most often using something like `git log --first-parent`. In my --no-ff integration branch that just shows me an integrated change list (PR list). Git gives me a "straight line" view down the DAG and hides irrelevant information I don't want in that moment like all the small "commit" commits.

If for some reason I find a bug or issue in some code, I may need to drill down into specific small commits including the "commit" commits, and I have that ability because all those commits are still in the DAG.