is to have good commit messages. They can be very
helpful to understand why some changes were made.

These general best practices are very helpful if you bisect often.

Avoiding bug prone merges
~~~~~~~~~~~~~~~~~~~~~~~~~

First merges by themselves can introduce some regressions even when
the merge needs no source code conflict resolution. This is because a
semantic change can happen in one branch while the other branch is not
aware of it.

For example one branch can change the semantic of a function while the
other branch add more calls to the same function.

This is made much worse if many files have to be fixed to resolve
conflicts. That's why such merges are called "evil merges". They can
make regressions very difficult to track down. It can even be
misleading to know the first bad commit if it happens to be such a
merge, because people might think that the bug comes from bad conflict
resolution when it comes from a semantic change in one branch.

Anyway "git rebase" can be used to linearize history. This can be used
either to avoid merging in the first place. Or it can be used to
bisect on a linear history instead of the non linear one, as this
should give more information in case of a semantic change in one
branch.

Merges can be also made simpler by using smaller branches or by using
many topic branches instead of only long version related branches.

And testing can be done more often in special integration branches
like linux-next for the linux kernel.

Adapting your work-flow
~~~~~~~~~~~~~~~~~~~~~~~

A special work-flow to process regressions can give great results.

Here is an example of a work-flow used by Andreas Ericsson:

* write, in the test suite, a test script that exposes the regression
* use "git bisect run" to find the commit that introduced it
* fix the bug that is often made obvious by the previous step
* commit both the fix and the test script (and if needed more tests)

And here is what Andreas said about this work-flow <<5>>:

_____________
To give some hard figures, we used to have an average report-to-fix
cycle of 142.6 hours (according to our somewhat weird bug-tracker
which just measures wall-clock time). Since we moved to Git, we've
lowered that to 16.2 hours. Primarily because we can stay on top of
the bug fixing now, and because everyone's jockeying to get to fix
bugs (we're quite proud of how lazy we are to let Git find the bugs
for us). Each new release results in ~40% fewer bugs (almost certainly
due to how we now feel about writing tests).
_____________

Clearly this work-flow uses the virtuous circle between test suites
and "git bisect". In fact it makes it the standard procedure to deal
with regression.

In other messages Andreas says that they also use the "best practices"
described above: small logical commits, topic branches, no evil
merge,... These practices all improve the bisectability of the commit
graph, by making it easier and more useful to bisect.

So a good work-flow should be designed around the above 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"