Mercurial_ The Definitive Guide - Bryan O'Sullivan [69]
revision as good or bad without checking it out first.
If you supply a command it will be used for automatic bisection. Its exit
status will be used as flag to mark revision as bad or good. In case exit
status is 0 the revision is marked as good, 125 - skipped, 127 (command not
found) - bisection will be aborted and any other status bigger than 0 will
mark revision as bad.
options:
-r --reset reset bisect state
-g --good mark changeset good
-b --bad mark changeset bad
-s --skip skip testing changeset
-c --command use command to check changeset state
-U --noupdate do not update to target
use "hg -v help bisect" to show global options
The hg bisect command works in steps. Each step proceeds as follows.
You run your binary test. If the test succeeded, you tell hg bisect by running the hg bisect --good command.
If it failed, run the hg bisect --bad command.
The command uses your information to decide which changeset to test next.
It updates the working directory to that changeset, and the process begins again.
The process ends when hg bisect identifies a unique changeset that marks the point where your test transitioned from “succeeding” to “failing.”
To start the search, we must run the hg bisect --reset command.
$ hg bisect --reset
In our case, the binary test we use is simple: we check to see if any file in the repository contains the string “i have a gub”. If it does, this changeset contains the change that caused the bug. By convention, a changeset that has the property we’re searching for is “bad,” while one that doesn’t is “good.”
Most of the time, the revision to which the working directory is synced (usually the tip) already exhibits the problem introduced by the buggy change, so we’ll mark it as “bad.”
$ hg bisect --bad
Our next task is to nominate a changeset that we know doesn’t have the bug; the hg bisect command will “bracket” its search between the first pair of good and bad changesets. In our case, we know that revision 10 didn’t have the bug. (I’ll talk more about choosing the first “good” changeset later.)
$ hg bisect --good 10
Testing changeset 22:c4a8a1b1985d (24 changesets remaining, ~4 tests)
0 files updated, 0 files merged, 12 files removed, 0 files unresolved
Notice that this command printed some output:
It told us how many changesets it must consider before it can identify the one that introduced the bug, and how many tests that will require.
It updated the working directory to the next changeset to test, and told us which changeset it’s testing.
We now run our test in the working directory. We use the grep command to see if our “bad” file is present in the working directory. If it is, this revision is bad; if not, this revision is good.
$ if grep -q 'i have a gub' *
> then
> result=bad
> else
> result=good
> fi
$ echo this revision is $result
this revision is bad
$ hg bisect --$result
Testing changeset 16:e1f9bd22c281 (12 changesets remaining, ~3 tests)
0 files updated, 0 files merged, 6 files removed, 0 files unresolved
This test looks like a perfect candidate for automation, so let’s turn it into a shell function.
$ mytest() {
> if grep -q 'i have a gub' *
> then
> result=bad
> else
> result=good
> fi
> echo this revision is $result
> hg bisect --$result
> }
We can now run an entire test step with a single command, mytest.
$ mytest
this revision is good
Testing changeset 19:faf233531e55 (6 changesets remaining, ~2 tests)
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
A few more invocations of our canned test step command, and we’re done.
$ mytest
this revision is good
Testing changeset 20:03fb7a882290 (3 changesets remaining, ~1 tests)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ mytest
this revision is good
Testing changeset 21:768bc298a8db (2 changesets remaining, ~1 tests)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ mytest
this revision is good
The first bad revision is:
changeset: 22:c4a8a1b1985d