Z'
and Z commits should point to the same source code state (the same
"tree" in git parlance). That's because Z' result from applying the
same changes as Z just in a slightly different order.

So if we could just "replace" Z by Z' when we bisect, then we would
not need to add anything to a script. It would just work for anyone in
the project sharing the special branches and the replacements.

With the example above that would give:

-------------
      (BBC+BFC)-X1'-X2'-X3'-X4'-X5'-X6'-Z'-...
     /
...-Y-BBC-X1-X2-X3-X4-X5-X6-BFC-Z
-------------

That's why the "git replace" command was created. Technically it
stores replacements "refs" in the "refs/replace/" hierarchy. These
"refs" are like branches (that are stored in "refs/heads/") or tags
(that are stored in "refs/tags"), and that means that they can
automatically be shared like branches or tags among developers.

"git replace" is a very powerful mechanism. It can be used to fix
commits in already released history, for example to change the commit
message or the author. And it can also be used instead of git "grafts"
to link a repository with another old repository.

In fact it's this last feature that "sold" it to the Git community, so
it is now in the "master" branch of Git's Git repository and it should
be released in Git 1.6.5 in October or November 2009.

One problem with "git replace" is that currently it stores all the
replacements refs in "refs/replace/", but it would be perhaps better
if the replacement refs that are useful only for bisecting would be in
"refs/replace/bisect/". This way the replacement refs could be used
only for bisecting, while other refs directly in "refs/replace/" would
be used nearly all the time.

Bisecting sporadic bugs
~~~~~~~~~~~~~~~~~~~~~~~

Another possible improvement to "git bisect" would be to optionally
add some redundancy to the tests performed so that it would be more
reliable when tracking sporadic bugs.

This has been requested by some kernel developers because some bugs
called sporadic bugs do not appear in all the kernel builds because
they are very dependent on the compiler output.

The idea is that every 3 test for example, "git bisect" could ask the
user to test a commit that has already been found to be "good" or
"bad" (because one of its descendants or one of its ancestors has been
found to be "good" or "bad" respectively). If it happens that a commit
has been previously incorrectly classified then the bisection can be
aborted early, hopefully before too many mistakes have been made. Then
the user will have to look at what happened and then restart the
bisection using a fixed bisect log.

There is already a project called BBChop created by Ealdwulf Wuffinga
on Github that does something like that using Bayesian Search Theory
<<9>>:

_____________
BBChop is like 'git bisect' (or equivalent), but works when your bug
is intermittent. That is, it works in the presence of false negatives
(when a version happens to work this time even though it contains the
bug). It assumes that there are no false positives (in principle, the
same approach would work, but adding it may be non-trivial).
_____________

But BBChop is independent of any VCS and it would be easier for Git
users to have something integrated in Git.

Conclusion
----------

We have seen that regressions are an important problem, and that "git
bisect" has nice features that complement very well practices and
other tools, especially test suites, that are generally used to fight
regressions. But it might be needed to change some work-flows and
(bad) habits to get the most out of it.

Some improvements to the algorithms inside "git bisect" are possible
and some new features could help in some cases, but overall "git
bisect" works already very well, is used a lot, and is already very
useful. To back up that last claim,