Trigger-warning, this is all highly opinionated. If you feel different about it, let's discuss 😄

It bases on my assumption, that a "clean" git history is something I might want to achieve but I don't necessarily need to achieve and the tradeoff between what I get by a clean history and the work I have to do for it seems to be negative for teams below enterprise-level size. Therefore commits about "lint fixes" are totally okay imo.

Here are some rather technical arguments:

• good commit messages are much more of importance; you can use a convention for commit messages that describes lint fixes; example:

"fix(ui): eslint compliance"

• if you use a convention then you can easily filter these commits:

git log --invert-grep --grep="eslint compliance"

• you can still use git squash-merge if a clean history is of most importance

Here are some rather human arguments:

• for newcomers and beginners it's often much easier to first commit the work they have done (feel safe; make sure things a working) and then apply formatting, refactoring etc.
• convention over configuration does imo also apply to the dev environment, which is why I regularly omit pre-commit hooks
• I also like to avoid to put my juniors into a skinner-box that only lets them pass, once they behave as I intend them to; rather I'd like them to learn conventions

What do you think? Something is missing? Is this unprofessional and I should never step a foot into your company's door? Let's discuss 😄