3 ms·
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
by Cthulhu_ 1y ago
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 1y agopre-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 1y agoI 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 1y agoCI 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 1y agoOne 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 1y agoA CI system can run the precommit hooks, and fail if any files are changed or the hooks don't exit successfully.