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.

▲

bapak a day ago | parent | next [-]

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.

▲

ali_piccioni a day ago | parent | prev | next [-]

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.

	▲	pxc a day ago \| parent [-]
		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.

▲

emmelaich a day ago | parent | prev | next [-]

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.

▲

SAI_Peregrinus a day ago | parent | prev [-]

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