Huh. Never thought of it that way. I was never bothered by a long commit history at all. Search and filter tools in the git client always get me where I want.

The one issue I have is when there are way too many extant branches and the graph takes up happy half my screen.

But that's more of a Fork issue than it is a fundamental one. The Fork dev could conceivably find a solution for that.

Either way, I guess I see what you mean. I'm just not that strict about commits. Commits just for the linter aren't a thing since we have a pre-commit hook for that, and typo-fixing commits... Well, they happen, but they're typically not numerous enough that I'd find them to be any sort of issue.

As for whether I'd really want to revert a particular change -- while I work, yes. Afterwards, I see what you mean; i could probably squash 50 commits into 15 or something. But when I think about the time investment of reviewing every commit and thinking about how they ought to be grouped together before making my merge request... I have a lot of trouble convincing myself it's a good time investment.

Maybe I'd think otherwise if we had a huge team. We have maybe 10 devs on this project at any given time.