As a codebase gets larger and older, git bisect becomes invaluable. If you have not used it, you don't know what you're missing. A pre-condition for git bisect

As a codebase gets larger and older, git bisect becomes invaluable. If you have not used it, you don't know what you're missing. A pre-condition for git bisect working is that each commit must run well enough to successfully test for whatever behavior change is being tested for. Otherwise, you'll identify some commit where the code went from working to not working, but if it's just some idiotic typo instead of actually the change that you are looking for, you've lost. I'd rather have a git bisectable history that correctly reflects a steady progression of the product than one that records every typo some developer made for posterity. That I typo'ed a variable name in a version that never shipped to anybody and then had to commit "FIXUP" is not useful information. A clean commit that changes behavior, but is subsequently revealed to cause a regression against a test that won't be written for another two years, is incredibly valuable. Some of you say you don't get the appeal of a "clean" history; I say back I don't get the appeal of a pedantically historical view of history. I have never gone digging through some old history to figure out whether or not some particular piece of documentation was at some point in the past misspelled. Completely uninteresting. I have never cared about the process of how a particular thing was arrived at, with all the false starts, not to mention that if I did, trying to read a series of patches isn't how I'd want to do it. I have cared about being able to cherry-pick a single clean commit to backport some feature, I have cared about git bisect, and I have cared about the ability to revert a particular feature via "git revert" without having to figure out which discontinuous set of half-a-dozen patches need to be reverted because almost no commits from the past can be reverted without making fundamental breaks to the build, not for fundamental reasons, but because they introduce typos and break variable names and re-do accidental file deletions, etc. History as a log of work is way less interesting than history as a queryable and manipulable data structure representing the various mostly-valid states of your project, and the ability to manipulate those mostly-valid states at a project level. Composing two valid states of the project together to get a third is incredibly powerful, and when two valid states compose together to create an invalid state, there's real information of some kind there. This doesn't work if your history mostly consists of invalid states. Composing two invalid states of the project together to get another invalid state isn't a surprise, it produces and teaches nothing. This is why, whenever I can, I have a git pre-commit hook that checks the compile of everything and runs all my test cases. It's better for that to be the habit, and to have to occasionally bypass it for some reason, than for the default to be allowing any ol' commit to fundamentally break whatever. Doing it in a CI system is fine too; I do what I can to keep the local tests working but it's not always possible. The key is just that something is done to ensure validity is maintained.