Because a commit should be an "indivisible" unit, in the sense that "should this be a separate commit?" equates to "would I ever want to revert just these changes?".

IDK about your commit histories, but if I'd leave everything in there, there'd be a ton of fixup commits just fixing spelling, satisfying the linter,...

Also, changes requested by reviewers: those fixups almost always belong to the same commit, it makes no sense for them to be separate.

And finally, I guess you do technically give up some granularity, but you gain an immense amount of readability of your commit history.

[–] Eiri@lemmy.ca 1 points 3 hours ago

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.