4 ms·

Can't stand pre-commit hooks. I want zero delay on commits. Checks can be run against pull requests in a GitHub action runner; no reason to force me to run them

Can't stand pre-commit hooks. I want zero delay on commits. Checks can be run against pull requests in a GitHub action runner; no reason to force me to run them on my machine.

hambes 1y ago
zero delay on commit, but then an entire CI run and feedback loop just to fix a linter or formatting issue
- indentit 1y ago
  The solution could be a pre-push hook. I am also not a fan of pre-commit hooks because I just want to commit my wip changes. Not stash. Commit. It's fine if the auto formatting tool hasn't been run. If the pre-commit hook changes my files silently, that is a big no-no for me. I have had tools break things before and it makes it very hard to work out what happened. Having it fail to push means I get to choose how to fix up my commits - whether I want a new one for formatting changes etc or to go back and edit a commit for a cleaner public history.
  - rkomorn 1y ago
    I used to think pre-push was better than pre-commit but at some point I realized I was actually just kicking the can down the road and leaving bigger problems for myself. It's not downsides-free, but it's the better compromise for me. 100% agree on hooks being readonly. Username oddly relevant to context btw.
rkomorn 1y ago
Couldn't disagree more. Waiting for a CI step to tell me something's wrong when I could've found out locally is a waste of time. Sure, I can hand-run checks locally, but having a way of doing it "automatically" pre-push gives me consistency and saves time.
- nosefurhairdo 1y ago
  That's fine, but it shouldn't be enforced on all contributors. What matters is that failures don't get merged, not that they don't get committed.
  - rkomorn 1y ago
    Yeah. As long as "don't get merged" includes squashing so that whatever your (non)hooks didn't catch locally don't end up causing failures for rebases/merge conflict resolutions for others (assuming there are repo-level hooks people are expected to be using).

Can't stand pre-commit hooks. I want zero delay on commits. Checks can be run against pull requests in a GitHub action runner; no reason to force me to run them on my machine.

hambes 1y ago

zero delay on commit, but then an entire CI run and feedback loop just to fix a linter or formatting issue

indentit 1y ago
The solution could be a pre-push hook. I am also not a fan of pre-commit hooks because I just want to commit my wip changes. Not stash. Commit. It's fine if the auto formatting tool hasn't been run. If the pre-commit hook changes my files silently, that is a big no-no for me. I have had tools break things before and it makes it very hard to work out what happened. Having it fail to push means I get to choose how to fix up my commits - whether I want a new one for formatting changes etc or to go back and edit a commit for a cleaner public history.
- rkomorn 1y ago
  I used to think pre-push was better than pre-commit but at some point I realized I was actually just kicking the can down the road and leaving bigger problems for myself. It's not downsides-free, but it's the better compromise for me. 100% agree on hooks being readonly. Username oddly relevant to context btw.

rkomorn 1y ago

Couldn't disagree more. Waiting for a CI step to tell me something's wrong when I could've found out locally is a waste of time. Sure, I can hand-run checks locally, but having a way of doing it "automatically" pre-push gives me consistency and saves time.

nosefurhairdo 1y ago
That's fine, but it shouldn't be enforced on all contributors. What matters is that failures don't get merged, not that they don't get committed.
- rkomorn 1y ago
  Yeah. As long as "don't get merged" includes squashing so that whatever your (non)hooks didn't catch locally don't end up causing failures for rebases/merge conflict resolutions for others (assuming there are repo-level hooks people are expected to be using).