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