I really don't understand the advocacy of git bisect. Using git bisect boils down to figuring out at which point in the history a change happened that broke a test or introduced a bug. Having tried git-bisect five or six times, I've found it's way slower for me than the tried and true method of:
1. Something's broken. What part of the code is broken? (perhaps 5 minutes tops?)
2. git blame <file> (10 seconds)
3. which lines in the trouble area were changed recently (10 seconds)
4. git show <commit> to reveal what got changed in that commit and caused the problem
In 99% of these cases the git blame is just to see what the other programmer (or often myself) was trying to do at the time they broke the code -- in these cases it's obvious what's broken, just not why it was changed.
When it's nontrivial to figure out where the code is broken and I have no clue at which point in the history the code broke, it's still easier just to diff the broken code to a known good branch or commit and look for significant differences.
I guess where git bisect slows way down for me is that you have to devise code that will indicate definitively that the bug exists. It's really never faster for me than just eyeballing the troublesome code at that revision.
If nothing else, git bisect allows any user[0] to find when a bug they are experiencing was introduced to the codebase.
They do not need to be familiar with the code, the language, that module, the library, the developer or have anything more than the knowledge of how to check out/bisect the code base, and how to reproduce the bug.
For this it is an invaluable tool, and I can't count the number of times on the git mailing list that a simple bug report has allowed a developer to quickly locate the exact commit an issue was introduced and investigate further. A recent example is at [1].
[0] Here a user refers to any of 'technical user', 'developer', 'maintainer', 'original author', or really anyone who has the ability to check out the repository.
This idea can be extended even further, to users who do not know how to (or cannot) build the software in question.
One example of this is mozregressionfinder [1] that was created by Heather Arthur [2]. The tool automatically downloads Firefox nightly builds (in the same binary search pattern of bisect) and lets the user check for the bug they observed in each version. Once the nightly build where the bug was introduced is found, a Mercurial pushlog URL is displayed which can then be pasted into a bug report to aid developers in chasing down the bug.
If you work on a small code base, or if you know the code base perfectly, you might get away with your "tried and true method" most of the time.
But if you are working on a code base with hundreds of commits per month, I wish you a lot of luck. Your 10s of seconds might easily become days.
On a big codebase you might even want to automate bisecting as much as possible. See http://lwn.net/Articles/317154/ where Ingo Molnar says:
>>> for example git-bisect was godsent. I remember that years ago bisection of a bug was a very [laborious] task so that it was only used as a final, last-ditch approach for really nasty bugs. Today we can [autonomously] bisect build bugs via a simple shell command around "git-bisect run", without any human interaction!
That doesn't always fly for a large active project, and for regressions that aren't detected until weeks or perhaps months after they were introduced. I use exactly your technique and it works more than half the time, but for the rest it's really nice to have git bisect.
> I guess where git bisect slows way down for me is that you have to devise code that will indicate definitively that the bug exists.
Normally whoever found the problem should provide you with a test case. Once you fix the problem you'd add that to your unit tests to prevent future regressions.
Your codebase must be very simple, because you can pinpoint the problem to a single file. Imagine you have something as complex as the kernel, a non-trivial breakage, that you can not reproduce but somebody else can, somebody who has no clue about the files where the problem could possibly be. Or some user reports that kernel X works but X+3 doesn't, and there are thousands of commits in between. Good luck pointing to a single file. Those are the situations that git bisect was made for.
When you are doing maintenance programming, where you only ever understand small pieces of the code at a time (the ones relevant to the project you are currently working on), bisecting the history of your commits is a very powerful way of doing business. In one of my feature branches, I wrote added some /* ... */ style comments to a mysql script and used apostrophe's in the text of my comment. This can confuse mysql when it executes the script. I was not deploying the new scripts into my test environment after every commit (I was mostly working on the python back-end, and only adding comments to the mysql scripts because they explained something that was happening in the python code). Several commits later, I do a full deploy and I have new symptoms. It was only by backing up through my commit history that I was able to find the commit that first introduced the symptom, and it was only the fact that I write small commits that allowed me to discover the problem with the apostrophe's.
Generalizing, whenever you are making incremental changes to a complex system where you don't understand all of the effects of your changes without lots of testing, it makes sense to write small commits so that you can backtrack to see when an unintended behavior first surfaced.
Maintenance programming is one field in which this approach is crucial.
"What part of the code is broken? (perhaps 5 minutes tops?)"
I expect this is where the git bisect advocacy comes from. Bisecting down to the commit that caused the test to fail takes seconds. Then, you can start using the remaining process not unlike you mentioned to actually fix the bug.
It helps remove that initial hunt for the problem. When you narrow the problem to a specific commit it becomes quite clear what is wrong immediately, not having to filter through the myriad of changes that may have come after. That is, at least, where I have found it to be most useful.
git bisect allowed me, as a user, to track down a rendering bug in WINE which I would have no idea where to start on otherwise. There were approx 1000 commits between the two parts and the reproduction was not terribly quick (start up game, get to certain view, verify). It even handled the fact that there were two apparently unrelated commits (by filenames and commit time) which contributed to the bug, and that some in some revisions the game wouldn't even start.
This is only one example, and I rarely have a need for git bisect in the code that I generally work on (since I can mostly keep it in my head, and regressions are rare). But in large projects it's extremely useful.
I just updated program X that I'm not a developer for, and it crashes a bunch in really weird ways. I ask on the mailing list and nobody's seen the problem and it doesn't reproduce for anybody else. I can get it to crash on my machine in a few seconds of using it by doing certain things. The backtraces from the segfault are in different places each time.
I clone the git repo, and bisect from the previous version that worked. It eventually finds the commit that broke things, with which it becomes obvious what was wrong.
1. Something's broken. What part of the code is broken? (perhaps 5 minutes tops?)
2. git blame <file> (10 seconds)
3. which lines in the trouble area were changed recently (10 seconds)
4. git show <commit> to reveal what got changed in that commit and caused the problem
In 99% of these cases the git blame is just to see what the other programmer (or often myself) was trying to do at the time they broke the code -- in these cases it's obvious what's broken, just not why it was changed.
When it's nontrivial to figure out where the code is broken and I have no clue at which point in the history the code broke, it's still easier just to diff the broken code to a known good branch or commit and look for significant differences.
I guess where git bisect slows way down for me is that you have to devise code that will indicate definitively that the bug exists. It's really never faster for me than just eyeballing the troublesome code at that revision.