have been cases that i used it multiple times a day. My
average is roughly once a day.
_____________
So regressions are fought all the time by developers, and indeed it is
well known that bugs should be fixed as soon as possible, so as soon
as they are found. That's why it is interesting to have good tools for
this purpose.
Other tools to fight regressions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
So what are the tools used to fight regressions? They are nearly the
same as those used to fight regular bugs. The only specific tools are
test suites and tools similar as "git bisect".
Test suites are very nice. But when they are used alone, they are
supposed to be used so that all the tests are checked after each
commit. This means that they are not very efficient, because many
tests are run for no interesting result, and they suffer from
combinatorial explosion.
In fact the problem is that big software often has many different
configuration options and that each test case should pass for each
configuration after each commit. So if you have for each release: N
configurations, M commits and T test cases, you should perform:
-------------
N * M * T tests
-------------
where N, M and T are all growing with the size your software.
So very soon it will not be possible to completely test everything.
And if some bugs slip through your test suite, then you can add a test
to your test suite. But if you want to use your new improved test
suite to find where the bug slipped in, then you will either have to
emulate a bisection process or you will perhaps bluntly test each
commit backward starting from the "bad" commit you have which may be
very wasteful.
"git bisect" overview
---------------------
Starting a bisection
~~~~~~~~~~~~~~~~~~~~
The first "git bisect" subcommand to use is "git bisect start" to
start the search. Then bounds must be set to limit the commit
space. This is done usually by giving one "bad" and at least one
"good" commit. They can be passed in the initial call to "git bisect
start" like this:
-------------
$ git bisect start [BAD [GOOD...]]
-------------
or they can be set using:
-------------
$ git bisect bad [COMMIT]
-------------
and:
-------------
$ git bisect good [COMMIT...]
-------------
where BAD, GOOD and COMMIT are all names that can be resolved to a
commit.
Then "git bisect" will checkout a commit of its choosing and ask the
user to test it, like this:
-------------
$ git bisect start v2.6.27 v2.6.25
Bisecting: 10928 revisions left to test after this (roughly 14 steps)
[2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit
-------------
Note that the example that we will use is really a toy example, we
will be looking for the first commit that has a version like
"2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line
in the top level Makefile. This is a toy example because there are
better ways to find this commit with Git than using "git bisect" (for
example "git blame" or "git log -S<string>").
Driving a bisection manually
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At this point there are basically 2 ways to drive the search. It can
be driven manually by the user or it can be driven automatically by a
script or a command.
If the user is driving it, then at each step of the search, the user
will have to test the current commit and say if it is "good" or "bad"
using the "git bisect good" or "git bisect bad" commands respectively
that have been described above. For example:
-------------
$ git bisect bad
Bisecting: 5480 revisions left to test after this (roughly 13 steps)
[66c0b394f08fd89236515c1c84485ea712a157be] KVM: kill file->f_count abuse in kvm
-------------
And after a few more steps like that, "git bisect" will eventually
find a first bad commit:
-------------
$ git bisect bad
2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit
commit 2ddcca36c8bcfa251724fe342c8327451988be0d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sat May