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