bibisect stands for "binary bisect" and is intended to help QA for LibreOffice 3.5. Regressions are a most annoying artifact that unfortunately comes with software development and QA. However, regressions are a misfeature we want to deal with quick and early as they might get harder and harder to triage and fix as time passes.

Because the way git stores its stuff, this download:

•  http://people.canonical.com/~bjoern/bibisect-3.5.tar.lzma

contains:

• 53 complete Linux 64-bit office installs (compiled on Ubuntu 11.10, but should work elsewhere too) between the creation of the core repo and the -3-5 branchoff (that is ~5000 commits)
• at 450MB each, that would be ~22GB total
• however, it is only 749MB total download size, that is less than 15MB per installation

And one does not need to install them in parallel as one can switch through all of them with a quick "git checkout source-hash-XXXXXX" -- one switch costs <1 second).

Now how does one use this for cornering a regression? Well, this is where the power of bisecting comes in. First you download the tarball and unpack it:

> wget http://people.canonical.com/~bjoern/bibisect-3.5.tar.lzma
> tar --lzma -xf bibisect-3.5.tar.lzma
> cd bibisect-3.5
> # to verify your download was not corrupted do a: git tag -v latest
> # you need my gpg-key from https://launchpad.net/~bjoern-michaelsen for that

Then you get yourself the newest build included in the download and check if your bug it there:

> git checkout latest
> ./opt/program/soffice.bin

Then get the oldest build included in the download and check that the regression is not there:

> git checkout oldest
> ./opt/program/soffice.bin

If the bug is already present at this point, it is not a regression in the range that is covered by the download, but an even older bug.
If the bug is not there it is a regression in the range covered by the download and we can corner it down very well now. Do:

> git bisect start latest oldest

to start bisecting. Then repeat these commands:

> ./opt/program/soffice.bin
> git bisect good # if the bug is not there
> git bisect bad # if the bug is there

after some ~5 repetitions, git will tell you something like this:

9625329ea5a7e3e8475cd21c07726beec20573bd is the first bad commit
commit 9625329ea5a7e3e8475cd21c07726beec20573bd
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Thu Dec 8 12:29:59 2011 +0100

    source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
   
    commit 2d19e9bb07ccff3134f855812dddfda5c07b1fe4
    Author:     Jan Holesovsky <kendy@suse.cz>
    AuthorDate: Wed Nov 16 14:17:03 2011 +0100
    Commit:     Jan Holesovsky <kendy@suse.cz>
    CommitDate: Wed Nov 16 14:21:33 2011 +0100
   
        Kill one usage of chrel.sed to fix build.

Append that (the source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4 line is the important one) and the output of:

> git bisect log

Which should look something like this:

git bisect start 'latest' 'oldest'
# good: [2faf4bc12ab490370d2196dedbc8091f9b09d0a5] source-hash-418a35f4861e863feb39eec73f4a39a87fbcb1f3
git bisect good 2faf4bc12ab490370d2196dedbc8091f9b09d0a5
# bad: [b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4] source-hash-ce60138d339a5eb2a174a5d27063249acf2cac42
git bisect bad b6fca7e58854bc617c5fc9a75d1c1720b0d7e1a4
# good: [0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e] source-hash-71cbcb62028295a98ceee60cb4c4ee425bafcd2e
git bisect good 0a28a62d53e996cf66d86e9bfb63ddc6ade75b7e
# bad: [9625329ea5a7e3e8475cd21c07726beec20573bd] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
git bisect bad 9625329ea5a7e3e8475cd21c07726beec20573bd
# good: [89d91bb6074026dc0894bcdc6aaf8f6124102da7] source-hash-fb754a0df859e30255c25af8fa19bfaa75f257e7
git bisect good 89d91bb6074026dc0894bcdc6aaf8f6124102da7

to the bug and the developers will have a very good idea where your bug is -- in this case between the commits fb754a0df859e30255c25af8fa19bfaa75f257e7 (good) and 2d19e9bb07ccff3134f855812dddfda5c07b1fe4 (bad) on master. A:

> git log fb754a0df859e30255c25af8fa19bfaa75f257e7..2d19e9bb07ccff3134f855812dddfda5c07b1fe4

on the source repository will then show the 128 commits including the one that introduced the bug, making it a lot easier for the developer to close in on the culprit.
For more details, see:

• bisect in the git community book
• discussion on the developer list