5 ms·

Show HN: GetHooky – a language-agnostic Git hook manager

26 points by Ezpie 1y ago

Gys 1y ago
No mention of git hooks? Why install an extra tool for something that is already part of git? https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
- robertlagrant 1y ago
  It's a git hook manager.
- bubblyworld 1y ago
  Using git hooks directly almost always leaves you maintaining a small collection of bash scripts for installs, upgrades, config in the long run. Personally I'm fine with that but tooling can be nice, no? (in case it's not clear though these tools are wrappers - under the hood it's still git hooks like you linked)
ria1 1y ago
[dead]
ericyd 1y ago
There's always a spectrum of preference with these things. Personally I don't like git hooks for my workflows because I know CI will enforce the relevant checks. In addition, I am fine running an extra test or lint or build command before opening my PR to verify it works locally. Git hooks are a nice solution but for me they just slow down common operations so I'd rather not use them. This tool looks like a nice improvement over project-level configurations like Husky (in the npm space) because it's an individual configuration so I could just skip it, whereas husky gets configured for everyone.
- SOLAR_FIELDS 1y ago
  There are dozens of your type out there that I don’t understand. The “I don’t want no commit hooks running on my machine. I and only I control what happens on my local machine” purists. There’s at least one in every job I work. 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?
  - ericyd 1y ago
    Valid questions. For me it's two things: 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.
    - SOLAR_FIELDS 1y ago
      Yeah it seems a lot of this boils down to the myriad of ways people use git. I can imagine some ways are easier than others when using hooks. And githooks are “all or nothing” without an easy way to enable/disable them per hook - which I believe is one of the problems that OP aims to solve.
G1N 1y ago
No support for arm64 unfortunately :( OP, I tried installing via rosetta on macOS arm: arch -x86_64 sh -c "$(curl -fsSL https://raw.githubusercontent.com/ezpieco/gethooky/master/tools/install.sh)" And I get the following error: mv: fastcopy: open() failed (to): /usr/bin/hooky: Operation not permitted I curl'd and installed the x86 version manually into my ~/.zsh_scripts folder to get past this; I think for darwin clients you need to install to /usr/local/bin to get past perms errors (maybe just for arm macs?).
greatgib 1y ago
Now thanks to Go and Rust, every single tool that are recommended to be installed in developers computers and server are required to be "sh -c "$(curl -fsSL " installed... We are so cooked...
- Ezpie 1y ago
  well you don't really have to you can just install the binary from the release page in github, but I mean, then mv it to the required location in order for it to work globally. So I thought why not just create a bash script for that.
nodesocket 1y ago
What's the documentation site using and theme? Really like the look.
- sjoedev 1y ago
  Since it’s hosted on GitHub, I snooped through the repo, and it appears to be created using VitePress [1]. [1] https://vitepress.dev/ https://vitepress.dev/
  - Ezpie 1y ago
    yup its vitepress. I kind of got the idea of it from Husky. They also use vitepress too, so I thought why not?
john-tells-all 1y ago
Why would someone use this tool when `pre-commit` exists? 14k stars on GitHub: > 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.
- Ezpie 1y ago
  Quit simple. To use pre-commit you would need python installed, and to be honest, not everyone is going to install python just to install pre-commit right? Meanwhile GetHooky being a CLI tool just requires you to install the respective binary for your system, and done. 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.

26 points by Ezpie 1y ago

Gys 1y ago

No mention of git hooks? Why install an extra tool for something that is already part of git? https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

robertlagrant 1y ago
It's a git hook manager.
bubblyworld 1y ago
Using git hooks directly almost always leaves you maintaining a small collection of bash scripts for installs, upgrades, config in the long run. Personally I'm fine with that but tooling can be nice, no? (in case it's not clear though these tools are wrappers - under the hood it's still git hooks like you linked)

ria1 1y ago

[dead]

ericyd 1y ago

There's always a spectrum of preference with these things. Personally I don't like git hooks for my workflows because I know CI will enforce the relevant checks. In addition, I am fine running an extra test or lint or build command before opening my PR to verify it works locally. Git hooks are a nice solution but for me they just slow down common operations so I'd rather not use them. This tool looks like a nice improvement over project-level configurations like Husky (in the npm space) because it's an individual configuration so I could just skip it, whereas husky gets configured for everyone.

SOLAR_FIELDS 1y ago
There are dozens of your type out there that I don’t understand. The “I don’t want no commit hooks running on my machine. I and only I control what happens on my local machine” purists. There’s at least one in every job I work. 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?
- ericyd 1y ago
  Valid questions. For me it's two things: 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.
  - SOLAR_FIELDS 1y ago
    Yeah it seems a lot of this boils down to the myriad of ways people use git. I can imagine some ways are easier than others when using hooks. And githooks are “all or nothing” without an easy way to enable/disable them per hook - which I believe is one of the problems that OP aims to solve.

G1N 1y ago

No support for arm64 unfortunately :( OP, I tried installing via rosetta on macOS arm: arch -x86_64 sh -c "$(curl -fsSL https://raw.githubusercontent.com/ezpieco/gethooky/master/tools/install.sh)" And I get the following error: mv: fastcopy: open() failed (to): /usr/bin/hooky: Operation not permitted I curl'd and installed the x86 version manually into my ~/.zsh_scripts folder to get past this; I think for darwin clients you need to install to /usr/local/bin to get past perms errors (maybe just for arm macs?).

greatgib 1y ago

Now thanks to Go and Rust, every single tool that are recommended to be installed in developers computers and server are required to be "sh -c "$(curl -fsSL " installed... We are so cooked...

Ezpie 1y ago
well you don't really have to you can just install the binary from the release page in github, but I mean, then mv it to the required location in order for it to work globally. So I thought why not just create a bash script for that.

nodesocket 1y ago

What's the documentation site using and theme? Really like the look.

sjoedev 1y ago
Since it’s hosted on GitHub, I snooped through the repo, and it appears to be created using VitePress [1]. [1] https://vitepress.dev/ https://vitepress.dev/
- Ezpie 1y ago
  yup its vitepress. I kind of got the idea of it from Husky. They also use vitepress too, so I thought why not?

john-tells-all 1y ago

Why would someone use this tool when `pre-commit` exists? 14k stars on GitHub: > 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.

Ezpie 1y ago
Quit simple. To use pre-commit you would need python installed, and to be honest, not everyone is going to install python just to install pre-commit right? Meanwhile GetHooky being a CLI tool just requires you to install the respective binary for your system, and done. 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.