I scanned all of GitHub's "oops commits" for leaked secrets

Pre-commit hooks are client-side only and opt-in; I've always been a big proponent of pre-commit hooks, as the sooner you find an issue the cheaper it is to fix, but over time pre-commit hooks that e.g. run unit tests tend to take longer and longer, and some people want to do rapid-fire commits instead of being a bit more thoughtful about it.

pre-commits require discipline:

- enforce them on CI too; not useful for secrets but at least you're eventually alerted

- do not run tasks that take more than a second; I do not want my commit commands to not be instant.

- do not prevent bad code from being committed, just enforce formatting; running tests on pre-commit is ridiculous, imagine Word stopping you from saving a file until you fixed all your misspellings.

I moved all my precommit hooks to prepush hooks. I don’t need a spellchecker disrupting my headspace when I’m deep into a problem.

My developer environments are setup to reproduce CI test locally, but if I need to resort to “CI driven development” I can bypass prepush hooks with —-no-verify.

One good (and obviously bad) thing about Subversion was the ability to change history. As admin I was asked numerous times to change a commit message. To point to the correct Jira issue, for instance.

Also easier to enforce pre-commit, since it was done server side.

A CI system can run the precommit hooks, and fail if any files are changed or the hooks don't exit successfully.

CI driven development results in so many shitty commits, though, and it's so slow. I find it very miserable.

Pre-commit hooks should be much, much faster than most CI jobs; they should collectively run in less than a second if possible.