undefined | Better HN

0 pointsericyd9mo ago0 comments

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.

0 comments

Ezpie9mo ago

I can totally understand the point you're making there. I used to use VScode too few years ago, but now I use vim most of the time. So majority of the time I'm in my terminal so if the hook fails for me, it gives me the error, and I have zero problems with that. So I get what you mean there, but I mean, for those who live in their terminals git hooks kind of make sense, I mean after all, we see the error cause its the terminal after all.

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.

jmholla9mo ago

1) You can pass `--no-verify` to `git commit` and it will skip the hooks. An alias would make it even more ergonomic.

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.

SOLAR_FIELDS9mo ago

Unfortunately —-no-verify is all or nothing. If I have 10 hooks and only want to skip one of them it won’t do the job

Ezpie9mo ago

maybe git should fix this. Or maybe I could fix this internally in githooky maybe? I don't know, but I could give it a try, at least. How would you like the approach to be? Any ideas, I'll take it.

1 more reply

SOLAR_FIELDS9mo 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.

j / k navigate · click thread line to collapse

0 pointsericyd9mo ago0 comments

Valid questions. For me it's two things:

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.

0 comments

Ezpie9mo ago

jmholla9mo ago

1) You can pass `--no-verify` to `git commit` and it will skip the hooks. An alias would make it even more ergonomic.

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.

SOLAR_FIELDS9mo ago

Unfortunately —-no-verify is all or nothing. If I have 10 hooks and only want to skip one of them it won’t do the job

Ezpie9mo ago

maybe git should fix this. Or maybe I could fix this internally in githooky maybe? I don't know, but I could give it a try, at least. How would you like the approach to be? Any ideas, I'll take it.

1 more reply

SOLAR_FIELDS9mo ago

j / k navigate · click thread line to collapse