[Droobfest]

Yea... no.

An overly clean git history for me is a sign of too much perfectionism and greatly reduced productivity.

When I code I usually have a general idea of the stuff I want to include in my branch, but then I stumble upon bugs or code couplings which I need to fix for my feature to work. And then I include the fix into my feature branch, because it's just tedious to switch all the time and create 5 interdependent branches that need to be merged together anyway. Also as long as the feature branch itself is fairly clean then I don't give a rats ass about atomic commits.

And commits having to pass tests is just ludicrous. That's what the tests are for, so you can fix it before merging the branch. Don't go crazy on the commit level..

It depends a bit on the project, and how public it is. But in the end your git history never provides any benefit to customers and doesn't make your code better by itself. I hardly ever rewrite or rebase commits unless there's a good reason for it.

[lwall]

Kind of disagree.

As a developer who works with code base that's got a git history going back over a decade and lot of legacy parts that haven't been touched in a long while, written by devs who've long since left, I fairly frequently wish they'd been more careful with the commit history.

You do mention project context as being relevant, but if bug fixes and refactoring _can_ be decoupled, it's a kindness to pull-request reviewers (if there are any) to do so and keep PRs small. It's also helpful if something needs to be rolled back if the commit history is fairly coherent.

[Droobfest]

Well I'll admit there is still a balance to it.

I'll just say that the emphasis should be on clean branches and PR's much more than clean individual commits. And on good code much more than clean git branches.

If there's too much ceremony around branches and pull requests I tend to avoid small fixes because it's just much work and that definitely doesn't improve the quality of the code.

[slingnow]

Why are you comparing advice meant for _solo projects_ to a 10 year old legacy codebase written by many different developers?

[rob74]

As long as the bugfix is at least in a commit of its own so it can be cherry-picked into another branch if needed, that should work too...

[SilverRed]

The easy mode is just doing the work in another branch/merge request and then ticking the "squash on merge" checkbox. You may or may not want this depending on how important the individual commits are but sometimes you end up with 50 "fix it" commits that add no value.