Hacker News Reader

Comment by lloydatkinson | Hacker News Reader

I’ve used bisect a couple of times but really it’s a workaround for having a poor process. Automatic unit tests, CI/CD, should have caught it first.

It’s still very satisfying to watch run though, especially if you write a script that it can run automatically (based on the existing code) to determine if it’s a good or bad commit.

View on HN

It's not a workaround. In this case it seems like it, but in general you cannot always rely on your existing tests covering everything. The test you run in the bisect is often updated to catch something new which is reported. The process is often:

1. Start with working code

2. Introduce bug

3. Identify bug

4. Write a regression test

5. Bisect with new test

In many cases you can skip the bisect because the description of the bug makes it clear where the issue is, but not always.

Important addendum to 4 that can throw someone their first time - Put the new test in a new file and don't commit it to the repo yet. You don't want it to disappear or conflict with old versions of the test file when bisect checks old commits.

I've always liked having regression tests somewhat isolated anyway, so this works well with that.

This is one annoying footgun. It would be great if git could ignore some special .bisect directory during the entire process. This way the script doesn’t need a load of ../..

Create a .bisect directory and stick a gitignore inside it that ignores the folder. Or, add .bisect/ to a global gitignore file.

You can checkout the bisect script commit in another directoy. Or use $git bisect run $(git show ...).

> Automatic unit tests, CI/CD, should have caught it first.

Tests can't prove the absence of bugs, only their presence. Bugs or regressions will slip through.

Bisect is for when that happens and the cause is not obvious.

Sometimes you notice a problem that your unit tests didn't cover and want to figure out where it was introduced. That's where git bisect shines.

You can go back and efficiently run a new test across old commits.

I don't think it's that simple. For example: Show me the unit tests and CI/CD scripts you would write to prove your code is free from security holes.

Yet, once you've identified a hole, you can write a script to test for it, run `git biset` to identify what commit introduced the hole, and then triage the possible fallout.

Ideally, we should write bug-free code, but we can't. There are some tools to avoid bugs, tests are one of them. Those tools avoid them, but not mitigate. Bisect doesn't replace tests, it only helps find where the bugs are happening. After finding and fixing the bugs, it's a good idea to write a test covering that bug.

To sum up: bisect and tests are not in opposite sides, they complement each other

"We write unit tests so our code doesn't have bugs."

"What if the unit tests have bugs?"

Reply on news.ycombinator.com