"There's no need to see previous attempts" and "a new feature should be a single commit" are very different things. I mostly agree with the first and don't thin

"There's no need to see previous attempts" and "a new feature should be a single commit" are very different things. I mostly agree with the first and don't think it's worth saving a failed attempt at something just because it happened to get committed at some point, but I still regularly implement features in multiple commits. It's very normal to do some refactoring to make the new feature easier to implement and then implement the feature, and those are separate changes that should be separate commits. A commit that only changes formatting is a prime example of a useful secondary commit. Separating formatting changes from code changes makes it much easier to see what the actual functional changes were rather than them being hidden in a mess of non-functional changes.