This should be getting more attention. From the perspective of the master branch, it has the benefits of squashed merges without losing your commit history.
I'll often have a patch that has a few things going on:
1. Refactor code in one file
2. Fix a bug in another module uncovered by the newly refactored code (maybe a code path that hasn't been hit until now)
3. Some quick fixes made while I was looking at that code
...if I made a mistake in step 1, it's likely that step 2, step 3, or both would be useful to keep. If it's squashed and merged, it may be difficult to undo just step 1. And it's good communication to keep each as their own commit because each is its own atomic change.
And I can always squash things myself as I feel the need.
I'll often have a patch that has a few things going on:
1. Refactor code in one file
2. Fix a bug in another module uncovered by the newly refactored code (maybe a code path that hasn't been hit until now)
3. Some quick fixes made while I was looking at that code
...if I made a mistake in step 1, it's likely that step 2, step 3, or both would be useful to keep. If it's squashed and merged, it may be difficult to undo just step 1. And it's good communication to keep each as their own commit because each is its own atomic change.
And I can always squash things myself as I feel the need.