I've really never understood this obsession with "preserving" history. When I work on a feature or bug I tend to commit often, because it's cheap, and it can sa

I've really never understood this obsession with "preserving" history. When I work on a feature or bug I tend to commit often, because it's cheap, and it can save my ass if I go in a bad direction and break something that used to work in one of my previous commits. I subscribe to a code fast philosophy, and work quickly to explore the space, find unknowns, get a working solution, write tests, and do final cleanup, docs, and optimize if needed. As such this would be a common commit history for me that would end up in a small PR. A large PR for me might have 50+ commits. - initial prototype of feature x, mostly working - feature x working as intended in requirements - fixed edge cases not originally identified when thinking about feature x - rearchitect feature x a bit now that it's better understood - write tests for feature x, most pass - get all feature x unit tests pass - a few more test cases for feature x - and a couple of integration tests for feature x - code cleanup for feature x - fix typo from last code cleanup resulting in bug - better docs for feature x - fix typos in feature x docs - update main readme to include notes about feature x Can anyone explain to me the value in preserving this history, because I'm just not seeing it, and it would completely muddy up the overall git history. There's tons of intermediate work we're not concerned about preserving, like the notes I scribble on paper, so why are we so concerned about preserving all these commits? I admit there's a small chance it's useful in rare circumstances, but I'd rather optimize for the common scenario.