I'm less worried about nefarious things and more worried about incompetence. A careless rm -rf ${PWD}/build (or cp or whatever) can nuke/overwrite/etc. my files if it happens inside a folder with a space in it. Because of issues like this I really don't trust anyone to writing scripts that execute automatically on a random machine. Heck, I only barely trust me to do it for myself.
I think the parent is saying that there's just as high a chance of incompetence in the installer of a random third-party app, or the install script of an unvetted third-party package, as there is of a theoretical "post-clone script" of an arbitrary Git repo.
The difference, I would say, is that installers and packages are created by ops people, and Git hooks are written by developers or devops people. Decide for yourself which one is more likely to make a mistake that reformats your system. (It's actually a hard question: developers are usually more precise with syntax in languages [like Bash] where ambiguous syntax can be dangerous; while ops people are better at understanding the system-level implications of the actions they're asking the system to perform.)
(Also, unlike installers or packages, there's no reason for a Git repo's hooks to be privileged to do anything outside of the Git repo's cloned .git dir + worktree. If Git wanted synced scriptability, it would be a perfect case for application-level sandboxing, using system calls like OpenBSD's pledge(2).
> there's just as high a chance of incompetence in the installer of a random third-party app
This is what you're missing though. No proper programming language performs automatic word splitting on spaces. Only shell scripting languages like like Bash do. There's a reason I didn't conflate "script" with "app" like you guys have. Scripts are both missing critical features for robust coding and also make it really easy to play fast and loose with everything. "Decide for yourself which one is more likely to make a mistake that reformats your system" is exactly what I have done in making the distinction here.
It's as if I had written "I think automotive regulation is necessary; I'd be worried about car companies producing cars without safety features", and in response you're replying with "companies can make cars with a variety of safety features. They can include seat belts and airbags, even."
Like I was saying, it would make sense for Git to sandbox its hooks. One valid way of doing this is to replace arbitrary-executable hooks with hooks that run in a sandboxed scripting environment, such as an embedded Lua interpreter; or hooks that are compiled to target a sandboxed VM, such as ZeroVM, PNaCl, or (a different profile of) WASM.
I wasn’t suggesting that we actually allow devs to sync bash scripts around, although I was pointing out that that’s what we’re presently already doing with e.g. Debian package hook scripts.
