[the_duke]

Config based hooks seem to miss the mark though?

The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?

So not very useful at all...

I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.

[WorldMaker]

This seems to be a first step in that direction, though. Merging repo suggestions into one per-repo `.git/config` is still a big improvement over N `.git/hooks/$EVENT` files. Plus the new config format is directly mergeable, whereas the old hooks files often weren't without extra work (they had to point to one and only one shell command, which might be an arbitrary binary rather than a mergeable shell script; hence why "hooks managers" are as much shell script managers as hooks file maintainers and often were generally mutually exclusive/do not cooperate).

Obviously it still leaves the door open if there should be a `.githooks` or `.gitconfig` file in the committed worktree that can suggest changes to `.git/config` with fewer manual steps, but this first effort in minimizing the number of manual steps and simplifying those manual steps to a simpler merge is still quite useful.

Which is also before pointing out that the `git config` command is already quite scriptable as a simple merge tool. You could in theory replace a "hooks manager" install script with just a sequence of `git config set --local hook.$name.*` lines. You still have to figure out how to get the user to run that script just like installing any other hooks manager, but that's an easy script now to write.