What does Git's pre-push hook receive on stdin, and what can it check before a push?

## Where pre-push sits `pre-push` runs on the *pushing* machine, after Git has negotiated with the remote enough to know which refs would move, but before any objects are transferred. That timing is what makes it useful: unlike `pre-commit`, which sees one commit at a time, `pre-push` sees the whole set of commits about to become visible to other people, and it knows which remote they are going to. ## The two arguments Git calls the hook with the name and the location of the destination remote. With `git push origin main` those are `origin` and the configured URL. When a named remote is not used — pushing to a raw URL — Git passes the same value for both. A hook can therefore apply stricter rules to the shared remote than to a personal one. ## The stdin protocol The interesting information arrives on standard input, one line per ref being updated: ``` <local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF ``` For example, pushing a local `main` to `refs/heads/main` on the remote gives you the local tip and the remote's current tip. Two special cases matter and are the usual source of buggy hooks: - **The remote ref does not exist yet** (a brand-new branch): `<remote-object-name>` is the all-zeroes object name. There is no `A..B` range to compute, so a naive `rev-list old..new` silently examines nothing. The correct move is something like `git rev-list <local-oid> --not --remotes=<remote>`, which lists commits not already present on that remote. - **You are deleting a remote ref** (`git push origin --delete feature`): `<local-object-name>` is all zeroes. There is nothing to inspect; skip the line. A push can update several refs in one invocation, so the hook must loop over all input lines rather than reading one. ## What it is good for The checks that genuinely belong here are the ones that only make sense in aggregate or only matter once work becomes shared: - refusing to push commits whose subject starts with `WIP`, `fixup!` or `squash!`, which are meant to be rebased away first; - refusing a push whose target ref is a protected-looking branch name, catching the accidental `git push origin main`; - running a fast build or the tests relevant to the changed files — expensive per-commit, tolerable per-push; - scanning the newly added commits for large blobs or credential-shaped strings before they escape the laptop. ## Exit status Zero lets the push proceed. Non-zero aborts it, and Git pushes nothing at all — not even the refs whose lines the hook approved, because the veto is on the command, not on an individual ref. Whatever the hook prints goes to the developer's terminal, so print the offending commit and the rule it broke. ## Bypass and consequences `git push --no-verify` skips `pre-push`, and removing or unsetting the executable bit on the hook file has the same effect. So `pre-push` is a *seatbelt*, not a *lock*: it catches the honest mistake at the moment it would have become everyone's problem, but it stops nobody who intends to skip it. Anything that must be guaranteed has to be re-checked where the push is received. ## Cost and habit Because a push is a deliberate, less frequent act than a commit, `pre-push` tolerates a few seconds of work in a way `pre-commit` does not. Even so, a hook that runs a five-minute suite on every push trains people to type `--no-verify`, at which point the seatbelt is permanently unbuckled. Keep it to the checks whose value clearly exceeds the wait.