Skip to main content

Module registry

Module registry 

Source
Expand description

The hook registry — one table, one signature.

Before this, dispatch was a 20-arm match in main.rs and handlers had four different signatures (run(&args), run(&hook, &args), argo_lint(&args), …). Two costs, one of them real:

  • adding a hook meant touching a match arm, a module, and remembering which signature that one used;
  • the hook NAME was written twice — in the arm and as the shim’s filename — with nothing checking they agree. A shim the binary does not recognise exits 2 and blocks the commit; a handler with no shim is dead code. The consistency test below turns that pairing into something enforced.

Structs§

Ctx
Everything a hook is given. One shape for all of them, so a handler that needs the invoked name (ban-terms excludes its own source by it) or the hooks directory (the dispatchers glob it) does not need its own signature.
Overrides
Every severity override visible here, resolved the way --get resolves it.

Constants§

CHECKS
ENTRYPOINTS
name → handler. The single place a hook is registered. The four hook names git itself invokes. Everything else is a Check.

Functions§

all_stage_checks
Every check for one stage — built-ins first, then whatever this repository declares in amont.conf.
effective_key
Which configured KEY applies to check here, if any.
effective_override
The override git would actually apply for check, or None if there is none (or the value is not one this understands).
lookup
one_named
One check by name, whichever kind it is. Built-ins are searched first, which costs nothing because manifest::parse refuses a name a built-in already holds — the two guards together mean neither kind can shadow the other.
severity_key
The config key a severity override lives under.
severity_of
A check’s severity, after any per-repository override.
stage_checks
Built-in checks for one stage, in declared order.

Type Aliases§

HookFn