zlacker

>>fortui+(OP)
I struggle to see value with git hooks. They're an opt-in, easily opt-out way of calling shell scripts from my understanding--you can't force folks to run them, and they don't integrate/display nicely with CI/CD.

Why not just call a shell script directly? How would you use these with a CI/CD platform?

>>candid+6a
This might be a me problem but I extensively manipulate the git history all the time which makes me loathe git hooks. A commit should take milliseconds, not a minute.

>>schind+Ef
You do seem to be doing it wrong. Extensive manipulation of the record and slow hooks are both undesirable.

>>esafak+Eq
I would reckon cleaning up your branch before opening a pull request is good practice. I also rebase a lot, aswell as git reset, and I use wip commits.

Slow hooks are also not a problem in projects I manage as I don't use them.

>>schind+Tu
No, I would not and don't do that. It is better to leave the PR commits separate and atomic so reviewers can digest them more easily. You just squash on merge.

> Slow hooks are also not a problem in projects I manage as I don't use them.

You bypass the slow hooks you mentioned? Why even have hooks then?

>>esafak+Iv
I do leave PR commits separate. In my teams I don't set up pre-commit hooks altogether, unless others feel strongly otherwise. In projects where they are forced upon me I frequently --no-verify hooks if they are slow, as the linter runs on save and I run tests during development. CI failing unintentionally is usually not a problem for me.