3 ms·

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

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.

trenchpilgrim 1y ago
"We write unit tests so our code doesn't have bugs." "What if the unit tests have bugs?"
nixpulvis 1y ago
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.
- Izkata 1y ago
  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.
  - nixpulvis 1y ago
    I've always liked having regression tests somewhat isolated anyway, so this works well with that.
  - lloydatkinson 1y ago
    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 ../..
    - trenchpilgrim 1y ago
      Create a .bisect directory and stick a gitignore inside it that ignores the folder. Or, add .bisect/ to a global gitignore file.
    - 1718627440 1y ago
      You can checkout the bisect script commit in another directoy. Or use $git bisect run $(git show ...).
slang800 1y ago
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.
tmoertel 1y ago
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.
masklinn 1y ago
> 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.
lucasoshiro 1y ago
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
deleted 1y ago
[deleted]

trenchpilgrim 1y ago

"We write unit tests so our code doesn't have bugs." "What if the unit tests have bugs?"

nixpulvis 1y ago

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.

Izkata 1y ago
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.
- nixpulvis 1y ago
  I've always liked having regression tests somewhat isolated anyway, so this works well with that.
- lloydatkinson 1y ago
  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 ../..
  - trenchpilgrim 1y ago
    Create a .bisect directory and stick a gitignore inside it that ignores the folder. Or, add .bisect/ to a global gitignore file.
  - 1718627440 1y ago
    You can checkout the bisect script commit in another directoy. Or use $git bisect run $(git show ...).

slang800 1y ago

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.

tmoertel 1y ago

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.

masklinn 1y ago

> 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.

lucasoshiro 1y ago

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

deleted 1y ago

[deleted]