3 ms·

`git bisect` is an indispensible git trick. You give it commit where you know the bug exists, and one where you know it doesn't and it'll use binary search to

`git bisect` is an indispensible git trick. You give it commit where you know the bug exists, and one where you know it doesn't and it'll use binary search to help you find where the bug came from. It's absolutely wonderful.

HereBeBeasties 8y ago
I always struggle to see why people bang on about git bisect. You need tests to make it work. If you have tests, why aren't you running them continuously? If you're running them continuously, why do you need git bisect?
- BenjiWiebe 8y ago
  Because your tests didn't have 100% coverage.
- Narretz 8y ago
  If the bug is a regression, you write the test after finding it, and execute it with git-bisect. If the test starts to pass, you have the commit where it will fail.
  - HereBeBeasties 8y ago
    If I can write a failing test, I can likely fix it. If I am interested in seeing who broke it and when, I can run git blame on the thing I'm fixing. Given that my test suite is generally in the same repo as the code, I'd need to write something that patched my new test into the codebase at every git bisect commit, recompile and run it. I can see that this may occasionally be useful if you have an extremely hard to find bug, but for me it's pretty rare. In fact I've done this once, ever. Hence my skepticism when people describe this as "git's killer feature" or whatever other hyperbole.
- teraflop 8y ago
  Sure; if you never write code that contains bugs that your unit tests don't catch, then "git bisect" is probably useless to you. As for the rest of us mere mortals, we sometimes write code that has bugs without discovering those bugs right away. In a complex system, it might not be easy to observe an incorrect behavior and immediately deduce the root cause. "git bisect" allows you to retroactively track down the commit that introduced a behavior change, even if it was something you didn't originally think to test for.
- __turbobrew__ 8y ago
  It's useful for projects where maintaining tests is impractical such as the linux kernel. When someone tries to find a regression in the kernel they are probably going to write a test which grep's dmesg for a certain output, or sometimes the regression is a kernel panic and you are basically checking if your system crashes or not on each bisect step.
- deleted 8y ago
  [deleted]
- api_or_ipa 8y ago
  You don't really need automated tests. You can use a reproducible bug report as test input, then use git-diff to determine the first point it time it appears.

HereBeBeasties 8y ago

I always struggle to see why people bang on about git bisect. You need tests to make it work. If you have tests, why aren't you running them continuously? If you're running them continuously, why do you need git bisect?

BenjiWiebe 8y ago
Because your tests didn't have 100% coverage.
Narretz 8y ago
If the bug is a regression, you write the test after finding it, and execute it with git-bisect. If the test starts to pass, you have the commit where it will fail.
- HereBeBeasties 8y ago
  If I can write a failing test, I can likely fix it. If I am interested in seeing who broke it and when, I can run git blame on the thing I'm fixing. Given that my test suite is generally in the same repo as the code, I'd need to write something that patched my new test into the codebase at every git bisect commit, recompile and run it. I can see that this may occasionally be useful if you have an extremely hard to find bug, but for me it's pretty rare. In fact I've done this once, ever. Hence my skepticism when people describe this as "git's killer feature" or whatever other hyperbole.
teraflop 8y ago
Sure; if you never write code that contains bugs that your unit tests don't catch, then "git bisect" is probably useless to you. As for the rest of us mere mortals, we sometimes write code that has bugs without discovering those bugs right away. In a complex system, it might not be easy to observe an incorrect behavior and immediately deduce the root cause. "git bisect" allows you to retroactively track down the commit that introduced a behavior change, even if it was something you didn't originally think to test for.
__turbobrew__ 8y ago
It's useful for projects where maintaining tests is impractical such as the linux kernel. When someone tries to find a regression in the kernel they are probably going to write a test which grep's dmesg for a certain output, or sometimes the regression is a kernel panic and you are basically checking if your system crashes or not on each bisect step.
deleted 8y ago
[deleted]
api_or_ipa 8y ago
You don't really need automated tests. You can use a reproducible bug report as test input, then use git-diff to determine the first point it time it appears.