Why do hosted Git services rarely let tenants install raw pre-receive hooks on a repository?

## What the mechanism really is Git's receiving-side hooks are not a configuration surface. `pre-receive`, `update` and `post-receive` are executables in the receiving repository's hook directory, which `git receive-pack` runs when a push arrives. There is no sandbox, no declared interface beyond arguments and stdin, no resource limit and no language restriction. Whoever can write a file into that directory can run arbitrary code as the user that serves pushes. On a repository you administer, that unbounded power is precisely the point — it is how you express a rule Git has no built-in setting for. The interesting question is what changes when the repository lives on infrastructure somebody else operates. ## Four properties that do not survive multi-tenancy **Arbitrary code execution.** The hook runs as whatever user serves the push, on the provider's machine, with the repository's objects and refs at hand. Isolating that per tenant is not a small feature: it is a container boundary, a filesystem policy, a network policy and a resource limit around a step that used to be a `fork` and an `exec`. **Latency in the critical path.** Every push waits for the hook. A script that shells out to a slow network endpoint holds the connection open for a developer somewhere, and multiplied across tenants it becomes an availability problem for the push path itself — the one operation everyone depends on. **Failure amplification.** A non-zero exit rejects the push; a hook that crashes, hits a syntax error or exhausts memory exits non-zero. So a single mistake in a tenant's script turns into "nobody can push to this repository", and the tenant will report it as an outage of the service. **Non-portability of the deployment.** Hosted repositories move: they are replicated, resharded, migrated between hosts. A file sitting in a hook directory is host-local state with no version history, no review trail and no natural home in the repository's own content, so it has to be replicated and reconciled as a separate concern. ## Why a declarative rule is the tractable alternative If you accept those constraints, the design that falls out is a constrained rule language rather than a script. Declarative rules can be validated when they are written rather than when a push arrives, evaluated with bounded cost, reasoned about by the provider, recorded with an audit trail, and applied uniformly wherever the repository happens to be served. The price is expressiveness: anything the rule language cannot say, you cannot enforce that way — which is exactly why self-managed and enterprise deployments, where the operator *is* the tenant, tend to keep raw hooks available. ## What stays true regardless The Git-level substance does not change with the hosting model, and that is the part worth carrying into any interview answer: - The receiving side is the only place a push rule can bind. A client's `--no-verify` cannot reach it, and no local configuration can turn it off. - The vetoing hooks run **before** any ref is updated: `pre-receive` once for the push, `update` once per ref. Anything after that can only report. - Rejection semantics differ by hook — a non-zero `pre-receive` blocks every ref in the push, while `update` blocks a single one. - Whatever evaluates the rule sits in every contributor's push path, so its cost and its reliability are everyone's problem. ## The judgment being examined This is a question about where a control belongs, and the strong answer separates the *mechanism* from the *venue*. A rule enforced at the point changes are received is the only one you can honestly call enforced; how that enforcement is expressed — a script you own, or a declarative rule a provider evaluates — is a tradeoff between expressiveness and operability, and the shape of that tradeoff is set by who is carrying the operational risk. A candidate who can say plainly "a raw hook is arbitrary code in the push path of a shared system, so the constrained form exists to make it operable" has understood both halves. Be careful not to overclaim about any particular provider's feature set; the durable reasoning is about the mechanism, not about a settings screen.