The biggest problem with git pre-commit hooks is indeed that they aren't shared.
Even if I set up a pre-commit hook to fmt and provide
cargo xtask install-hooks every single person who contributes to the repository has to remember/be told to install it.
This does reduce the work from O(PRs) to O(contributors), which is an improvement.
But better, imho, would be a setup like IntelliJ IDEA's run configurations: assuming you're sharing the "shared IDE files" that IDEA uses (i.e. your team is uniformly using IDEA so putting those IDE files into VC is acceptable), run configurations default to being developer-local. However, you can check a box to share the run configuration, and it will then be shared through VC.
I don't know the inner workings of pre-commit hooks. If it uses executables under the hood, then they definitely aren't sharable between workstations. Adding user code to
git commit is also a potential security vulnerability, since you likely expect that to be a safe git-only operation.
I think the most tenable "shared pre-commit hook" would be for it to be a command line call to invoke a build system program that can do OS specific dispatch, and the call is somehow OS-independent, and on the first
git commit it prompts you to ask if you trust and would like to run the repository's pre-commit hook. (I assume you can trust anybody you pull from after the initial clone to review.)
This would be a rather involved change to git upstream, however, and wouldn't benefit us for a long time, even if it were to be accepted.
I hate to say "use x.py more", but one potential solution is to push people to use e.g.
./x.py commit, which would install the pre-commit
./x.py fmt and then shell out to git.