If the thing is going to block in ci anyway, why are you opting for a push and pray approach? Why arbitrarily increase your feedback loop time and add waiting time for each loop in ci? Chances are the time to get feedback is at least a couple orders of magnitude faster locally, you’re paying not only the startup time to register the runner and bring it online, get dependencies installed etc but also the manual time to context switch to the CI window etc. Just do all your linting and auto formatting and whatever on commit. It’s all work you’re going to have to do anyway, why introduce some extra less efficient step on yourself to slow yourself down?
1) sometimes hooks are configured on commit, and I prefer to have a very quick and lightweight commit action. If I'm changing branches sometimes I'll commit WIP changes so I can easily come back to it later. I know git stash accomplishes a very similar functionality but it's just a preferred workflow.
2) I don't like the feedback I get from git hooks when committing in the VS Code interface. For example, we have a "lint" hook that runs on pre-push. When it fails, I have to run "lint" manually in my terminal anyway to actually see the errors, because VS Code doesn't show me the actual errors. I believe the hook results are available in some other tab or something but I haven't bothered to learn it.
Both of these are just personal preferences, and maybe a little bit of resistance to learning new workflows. I don't consider myself a purist about it and I've never argued about it at work but hopefully this sheds a little light on my perspective.
Edit: regarding the "push and pray" approach, I personally don't do that, I'll run it locally first, I just prefer to run it myself rather than via a hook.
So yeah it just boils down to the fact how you would use git, in vscode, hooks aren't great, cause its not going to display the error, but if you use the terminal, even in vscode, you'll see the error getting displayed on the terminal.
2) You can write hooks that make the changes for you where possible. This is what I do for lints from auto-formatters. Don't know how to handle the rest of your VS Code issues though.
I have no issues in accepting PRs it would be cool to see how you can cook this up.
arch -x86_64 sh -c "$(curl -fsSL https://raw.githubusercontent.com/ezpieco/gethooky/master/tools/install.sh)"
mv: fastcopy: open() failed (to): /usr/bin/hooky: Operation not permitted
We are so cooked...
> multi-language package manager for pre-commit hooks
I'm all for having options, I'm just curious at what GetHooky brings to the table.
Also, pre-commit's approach of creating a YAML file and then running your pre-commit hook is a bit overengineering, in my opinion. I mean, what if I just want to run pytest? A whole YAML file sounds a bit unnecessary work to me. But with GetHooky, it's simple. Just use the add command and then the install command, and your job is done. Nothing much complicated.
Hope this helped you clarify what exactly GetHooky is, its not a package that requires you to install a language for its runtime, its a CLI tool, just download the binary and done.
Gys•7mo ago
robertlagrant•7mo ago
bubblyworld•7mo ago
(in case it's not clear though these tools are wrappers - under the hood it's still git hooks like you linked)