Home Explore Blog CI



git

13th chunk of `Documentation/git-bisect-lk2009.adoc`
783a852e6ab82a1650ebabc16e161312efcd94bc8a7c3a7b0000000100000fa2
 points. That
is making bisecting easier, more useful and standard.

Involving QA people and if possible end users
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

One nice about "git bisect" is that it is not only a developer
tool. It can effectively be used by QA people or even end users (if
they have access to the source code or if they can get access to all
the builds).

There was a discussion at one point on the linux kernel mailing list
of whether it was ok to always ask end user to bisect, and very good
points were made to support the point of view that it is ok.

For example David Miller wrote <<6>>:

_____________
What people don't get is that this is a situation where the "end node
principle" applies. When you have limited resources (here: developers)
you don't push the bulk of the burden upon them. Instead you push
things out to the resource you have a lot of, the end nodes (here:
users), so that the situation actually scales.
_____________

This means that it is often "cheaper" if QA people or end users can do
it.

What is interesting too is that end users that are reporting bugs (or
QA people that reproduced a bug) have access to the environment where
the bug happens. So they can often more easily reproduce a
regression. And if they can bisect, then more information will be
extracted from the environment where the bug happens, which means that
it will be easier to understand and then fix the bug.

For open source projects it can be a good way to get more useful
contributions from end users, and to introduce them to QA and
development activities.

Using complex scripts
~~~~~~~~~~~~~~~~~~~~~

In some cases like for kernel development it can be worth developing
complex scripts to be able to fully automate bisecting.

Here is what Ingo Molnar says about that <<7>>:

_____________
i have a fully automated bootup-hang bisection script. It is based on
"git-bisect run". I run the script, it builds and boots kernels fully
automatically, and when the bootup fails (the script notices that via
the serial log, which it continuously watches - or via a timeout, if
the system does not come up within 10 minutes it's a "bad" kernel),
the script raises my attention via a beep and i power cycle the test
box. (yeah, i should make use of a managed power outlet to 100%
automate it)
_____________

Combining test suites, git bisect and other systems together
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

We have seen that test suites and git bisect are very powerful when
used together. It can be even more powerful if you can combine them
with other systems.

For example some test suites could be run automatically at night with
some unusual (or even random) configurations. And if a regression is
found by a test suite, then "git bisect" can be automatically
launched, and its result can be emailed to the author of the first bad
commit found by "git bisect", and perhaps other people too. And a new
entry in the bug tracking system could be automatically created too.


The future of bisecting
-----------------------

"git replace"
~~~~~~~~~~~~~

We saw earlier that "git bisect skip" is now using a PRNG to try to
avoid areas in the commit graph where commits are untestable. The
problem is that sometimes the first bad commit will be in an
untestable area.

To simplify the discussion we will suppose that the untestable area is
a simple string of commits and that it was created by a breakage
introduced by one commit (let's call it BBC for bisect breaking
commit) and later fixed by another one (let's call it BFC for bisect
fixing commit).

For example:

-------------
...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z-...
-------------

where we know that Y is good and BFC is bad, and where BBC and X1 to
X6 are untestable.

In this case if you are bisecting manually, what you can do is create
a special branch that starts just before the BBC. The first commit in
this branch should be the BBC with the BFC squashed into it. And the
other commits in the branch

Title: Expanding the Use of Git Bisect and Automation
Summary
This text explores the benefits of involving QA people and end users in the bisecting process, as they can provide valuable insights and access to the environment where bugs occur. It also discusses the use of complex scripts to automate bisecting, combining test suites and git bisect with other systems, and the potential of 'git replace' to simplify the bisecting process. Additionally, it touches on the idea of fully automating bisecting and integrating it with bug tracking systems to streamline the debugging process.