[jayd16]

Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?

CI should also run all the checks but CI checks are not a replacement for local hooks. LFS and things like it can't be implemented as remote CI checks.

Why are we acting like a James Bond villain, slowly lowering the changes into the vat of sharks after we've left the room? I want the hooks. Can we talk about making that easy, assuming some people want them?

[n_e]

> Why waste a round trip, build time, loss of flow and CI machine queue wait time when you can catch things early?

Because we want to be sure that the checks have passed, and that they have passed in a clean environment.

Contributors can, in addition, use git hooks, or run tests in watch mode, or use their IDE.

Also it's annoying to have slow git hooks if you commit often.

[crote]

You're looking for a technological solution for a human problem.

Automatically running arbitrary code from random repositories is a Really Bad Idea, so Git will almost certainly never auto-install pre-commit hooks. Just mention it in the README and run a checker in CI to confirm they are using it, it really isn't that difficult.

People wasting 2 minutes of their own time once during their first contribution because they didn't read the README is not that big of a deal. What's next, you want a script to automatically sign a project's legally-binding CLA on checkout?

[jayd16]

You're talking out of both sides of your face here. It's dangerous and also it's super easy and you should do it first thing without having to think because it's so easy. You shouldn't run this code but also the build machine automatically runs it.

We already know we're definitely going to run some of these. We know we want to maintain changes to these hooks. Can we stop pretending like we're not doing that? We get it. Some of these will be untrusted so let's design a system to handle that instead of not designing a system and deciding to be just short of as unsafe as possible.

Automation an uniformity increases safety. Human intervention increases human error. Its just a matter of actually finding a good solution to know what is trusted but instead we get "just set it up manually because its safer."

[crote]

In one case you are asking Git to run untrusted and unvetted code from a repository of unknown provenance you just cloned - without any kind of branch restrictions or sandboxing. Oh, you clone and check out a branch of some random leftpad fork you come across? Sure, let's immediately run their post-checkout shell script! It's like automatically running "curl | sh" on every random website you visit.

In the other case the repo owner itself is asking it to run pre-vetted code in a controlled sandbox - and only for branches where it is explicitly enabled. It's like running "wc -l", in a sandbox, on mostly-trusted input files.

[krzyk]

Local hooks are just a convenience. CI checks are assurances, you have to have them.

If one hates the round-trip he/she will adopt hooks quickly.

[jayd16]

LFS hooks are not just a convenience, for example. CI, despite being a useful thing in its own right, is not a replacement.

[krzyk]

Fair, I don't use LFS so I don't know how it works.

I was writing more in regards of hooks as "checks" for workflow/lints/etc.