hghooks directory contains a number of Mercurial hooks used by
The content of this directory originally derived from its own
the import of this repository.
This directory has its origins in the operation of the Mercurial server at Mozilla. It is an eventual goal to restructure the hooks to be usable on both client and server.
Older versions of Mercurial had a bug where the set of modified files stored in the commit object were incomplete. Operations that relied on this cached set of changed files (hooks, some revset queries, log) could have inaccurate output if a buggy commit was present.
This hook looks for the presence of buggy metadata and rejects it.
This hook attempts to enforce that commit messages are well-formed. It is targeted towards the Firefox commit message standard.
This hook prevents file renames that only change the case of a file. e.g.
FOO would be disallowed.
This hooks exists to prevent issues with case-insensitive filesystems.
This hook is used to prevent changes to strings in string frozen release heads without the explicit approval from l10n-drivers.
This hook prevents changes to WebIDL files that shouldn’t be made.
All WebIDL changes must be reviewed by a DOM peer and this hook enforces that.
This hook prints relevant information about a push that just completed.
It will print the URL of the changesets on https://hg.mozilla.org/. It will also print TreeHerder URLs for Try pushes.
This hook enforces that all Mercurial branches contain at most one head.
This hook prevents pushes to Firefox repositories that are currently closed.
This hook enforces the requirement that pushes to the Try repository contain Try job selection syntax.
This hook enforces a whitelist of accounts that are allowed to push to certain Release Engineer repositories.
Hook Development Standards¶
Hooks are written and loaded into Mercurial as Python modules. This goes against recommendations by the Mercurial project. However, we do this for performance reasons, as spawning new processes for hooks wastes valuable wall time during push. (Mercurial recommends against in-process hooks because they don’t make promises about the stability of the internal API.)
Hooks should be unit tested via
.t tests and should strive for 100%
code coverage. We don’t want any surprises in production. We don’t want
to have to manually test hooks when upgrading Mercurial. We should have
confidence in our automated tests.
pretxnchangegroup) hooks should filter the
source and always return success for these. If an
hg strip operation
is running, the changesets already got into the repository, so a hook
has no business checking them again.
Any hook change touching a Mercurial API should be reviewed by someone who
knows Mercurial internals. You should default to getting review from
Hooks connecting to external systems or performing process that could be
deferred will be heavily scrutinized. We want
hg push operations to
be fast. Slow services, networks, or CPU or I/O intensive hooks all
undermine that goal.