Using Custom Commit Hooks with Mercurial


Custom commit hooks can be created for Mercurial. Chapter 10 of Mercurial: The Definitive Guide elaborates on how to accomplish this.

If you are looking to enforce bug IDs in changeset commit messages, a custom hook would be what you need.  The hook will need to be distributed to each client-side machine.

However, such hooks won’t allow you to prevent developers from getting changesets without bug IDs into Kiln; it’ll only stop them from doing so if they install your hooks and don’t override them.

To flat-out stop someone from pushing changesets without bug IDs, we’d really have to provide some mechanism for executing code on our servers, so that we could check your constraints in real-time. While we have built a lot of infrastructure in FogBugz to handle that kind of thing, that’s not been integrated into Kiln at all. It’d be a major undertaking.

Even if we implemented that, though, rejecting malformed changesets on the server probably isn’t what you want. Because DVCSes let you commit offline, you could get a user wedged where the only way for them to submit changes—perhaps a substantial chunk—that they’d already written, would be either to redo them, or to edit their history.

So if you really want to rigorously enforce this in Kiln, one suggestion would be as follows:

  1. Make the canonical repository one that only one person has access to
  2. Use one Kiln branch repository per submitter for incoming code
  3. Whenever someone pushes a meaningful amount of code, assign a code review to the person with push access to the central repository. If they approve, they should push.

This means that you can safely push a commit message where you forgot a bug ID, but everything actually getting accepted into the main repository matches your criteria.