Mercurial_ The Definitive Guide - Bryan O'Sullivan [71]
Another useful situation in which to use hg bisect --skip is if you can’t test a revision because your project was in a broken and hence untestable state at that revision, perhaps because someone checked in a change that prevented the project from building.
Bracket Your Search Lazily
Choosing the first “good” and “bad” changesets that will mark the end points of your search is often easy, but it bears a little discussion nevertheless. From the perspective of hg bisect, the “newest” changeset is conventionally “bad,” and the older changeset is “good.”
If you’re having trouble remembering when a suitable “good” change was so that you can tell hg bisect, you could do worse than testing changesets at random. Just remember to eliminate contenders that can’t possibly exhibit the bug (perhaps because the feature with the bug isn’t present yet) and those where another problem masks the bug (as I discussed above).
Even if you end up “early” by thousands of changesets or months of history, you will only add a handful of tests to the total number that hg bisect must perform, thanks to its logarithmic behavior.
Chapter 10. Handling Repository Events with Hooks
Mercurial offers a powerful mechanism to let you perform automated actions in response to events that occur in a repository. In some cases, you can even control Mercurial’s response to those events.
The name Mercurial uses for one of these actions is a hook. Hooks are called “triggers” in some revision control systems, but the two names refer to the same idea.
An Overview of Hooks in Mercurial
Here is a brief list of the hooks that Mercurial supports. We will revisit each of these hooks in more detail later, in Information for Writers of Hooks.
Each of the hooks whose description begins with the word “Controlling” has the ability to determine whether an activity can proceed. If the hook succeeds, the activity may proceed; if it fails, the activity is either not permitted or undone, depending on the hook.
changegroup: This is run after a group of changesets has been brought into the repository from elsewhere.
commit: This is run after a new changeset has been created in the local repository.
incoming: This is run once for each new changeset that is brought into the repository from elsewhere. Notice the difference from changegroup, which is run once per group of changesets brought in.
outgoing: This is run after a group of changesets has been transmitted from this repository.
prechangegroup: This is run before starting to bring a group of changesets into the repository.
precommit: Controlling. This is run before starting a commit.
preoutgoing: Controlling. This is run before starting to transmit a group of changesets from this repository.
pretag: Controlling. This is run before creating a tag.
pretxnchangegroup: Controlling. This is run after a group of changesets has been brought into the local repository from another, but before the transaction completes that will make the changes permanent in the repository.
pretxncommit: Controlling. This is run after a new changeset has been created in the local repository, but before the transaction completes that will make it permanent.
preupdate: Controlling. This is run before starting an update or merge of the working directory.
tag: This is run after a tag is created.
update: This is run after an update or merge of the working directory has finished.
Hooks and Security
Hooks Are Run with Your Privileges
When you run a Mercurial command in a repository, and the command causes a hook to run, that hook runs on your system, under your user account, with your privilege level. Since hooks are arbitrary pieces of executable code, you should treat them with an appropriate level of suspicion. Do not install a hook unless you are confident that you know who created it and what it does.
In some cases, you may be exposed to hooks that you