If pre-commit can not mutate the commit

It seems difficult for pre-commit to mutate the commit. For example, using this hook:

git commit --amend --allow-empty --no-verify -m QUACK

...produces this error:

$ git commit --allow-empty -m 'NO QUACKS ALLOWED'
[master 7b454a1] QUACK
 Date: Fri May 8 13:47:19 2020 -0700
fatal: cannot lock ref 'HEAD': is at 7b454a12a2567bf4a66c8cdd13224310b3b83419 but expected 378d91e344736a7c5c7babef8cb6caf8bdf28b98

Later, pre-push can do whatever it wants (the command above works fine in pre-push), but it only applies locally: git still pushes refs to the remote by commit hash, as far as I can tell. So pre-push can make your local working copy look nothing like the remote, but doesn't seem to be able to make a different set of changes get pushed to the remote.

Finally, post-commit can do whatever it wants and definitely breaks things and it is not disabled by --no-verify! As far as I can tell, nothing short of moving the hook aside can disable post-commit.

So this whole thing is sort of a fool's errand and a determined user can shoot themselves in the foot with post-commit more or less no matter how hard we try to prevent it, with the caveat that they have to be aiming for their foot hard enough to include a mechanism that prevents the hook from re-entering itself over and over again.

Notably, this seems to be not-exactly-true, although it obviously means "git ignores the exit code of the hook":

$ git help githooks

...

   post-commit
       ...

       This hook ... cannot affect the outcome of git commit.