Using Git hooks on the receiving repository, how would you reject a push containing a badly formatted commit message?

## Why pre-receive and not update The subject of the rule is the commits, not the ref. A `update` hook would run once per ref and would let a push land partially — `main` accepted, `develop` refused — which leaves the repository in a state nobody intended. `pre-receive` sees the whole push at once, and Git guarantees that if it exits non-zero, none of the refs are updated. That all-or-nothing property is exactly what a content rule wants. It also has to be a receiving-side hook rather than a client `commit-msg` hook if the rule is meant to bind: client hooks are not distributed by clone and are skipped by `--no-verify`, whereas this one runs on infrastructure the pusher does not control. ## Getting the commit list right This is where most implementations are subtly wrong. - **Ordinary update.** `git rev-list "$old..$new"` gives the commits reachable from the new tip but not the old one — the ones this push introduces to that ref. - **Branch creation.** The old object name is all zeroes, so `$old..$new` is not usable. Naively falling back to `git rev-list "$new"` walks the entire history and rejects the push because of a message someone wrote three years ago. The correct form is `git rev-list "$new" --not --all`, which excludes everything already reachable from any existing ref. - **Branch deletion.** The new object name is all zeroes; there is nothing to validate, so skip the line. - **Repeats across refs.** Pushing a branch and a tag that point into the same history yields the same commits twice. Deduplicate if you print per-commit output. The objects are already readable when the hook runs — in recent Git they sit in a quarantine area, pointed at by `GIT_QUARANTINE_PATH`, and are only migrated into the repository if the push is accepted — so `git log` and `git rev-list` work normally on them and a rejected push leaves nothing behind. ## The check itself Read the subject with `git log -1 --format=%s "$c"`, and the body with `%b` if the rule extends to it. Keep the pattern strict but small: a type prefix, a length ceiling, a required issue reference. Every extra clause is another rejection a contributor has to decode from a terminal at 6pm. Decide deliberately how merge commits are treated. Generated merge subjects rarely match a hand-written convention, and a hook that rejects them makes ordinary integration painful; excluding them with `git rev-list --no-merges` is the common choice. ## Reporting well Both stdout and stderr of `pre-receive` are relayed to the pushing client, so the hook can talk to the human. A good rejection message names the offending commit's abbreviated object name, shows the subject, states the rule in one line, and says how to fix it — for these commits, an interactive rebase, since the message is baked into the commit's identity. Collect every failure before exiting instead of stopping at the first: making someone rebase four times because you reported one problem per attempt is the fastest way to get your hook deleted. ## Cost and blast radius Every push in the organisation waits for this hook, and it runs on shared infrastructure. Bounding the walk to newly introduced commits keeps it proportional to the push rather than to the repository. A guard for absurd cases — a push introducing tens of thousands of commits — is worth having so an import does not hang the receive path. Think also about the failure mode of the hook itself. A crash or a syntax error in `pre-receive` is a non-zero exit, which means *every* push in the repository is now rejected. Keep the script simple, make it exit zero on any condition it does not understand rather than on any error it did not anticipate, and have a way to disable it. ## Where this rule really belongs Be honest in the interview that a receiving-side hook is the mechanism Git itself gives you, and that hosted environments often express the same intent as configured repository rules instead. The reasoning to show is the layering: the same pattern as a fast local `commit-msg` hook for immediate feedback, and this as the binding check — with both derived from one definition so they cannot drift.