ebabdce's message said setup-hooks.sh now activates the tracked hook instead of
generating a copy of it. The committed file was still the generator. This is that
change, for real.
How the wrong file got committed, since the mechanism is worth knowing: I wrote the new
setup-hooks.sh, ran it, then hit an unrelated bad test and undid it with `git reset
--hard HEAD~1`. setup-hooks.sh is TRACKED, so my uncommitted edit to it was reverted by
that reset -- while the new, UNTRACKED hooks/pre-commit survived, because reset --hard
does not touch untracked files. `git add setup-hooks.sh` then staged the restored
generator, and the commit described what I had written rather than what was in the tree.
Nothing failed loudly: the file was valid shell, shellcheck passed, and I verified the
HOOK's behaviour rather than the SCRIPT's, so the evidence I collected was real but
about the wrong file.
Effect of the defect: hooks/pre-commit and core.hooksPath were correct, so this clone
was gated the whole time. But anyone running ./setup-hooks.sh would have re-created
.git/hooks/pre-commit -- reinstating the very copy ebabdce removed, where it is now
INERT (core.hooksPath wins) and looks like protection while never running.
The activator now also VERIFIES its own effect: it reads core.hooksPath back and exits
1 if it is not 'hooks', because a gate that was never activated behaves exactly like one
with nothing to report. Checked before committing this time: 0 heredoc generators
present, core.hooksPath set at line 20, and running it creates NO .git/hooks/pre-commit.
joakimp