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.

▲

nixpulvis 4 days ago | parent | next [-]

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 4 days ago | parent [-]

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 4 days ago | parent | next [-]

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

▲

lloydatkinson 4 days ago | parent | prev [-]

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 4 days ago \| parent \| next [-]
		Create a .bisect directory and stick a gitignore inside it that ignores the folder. Or, add .bisect/ to a global gitignore file.
	▲	1718627440 4 days ago \| parent \| prev [-]
		You can checkout the bisect script commit in another directoy. Or use $git bisect run $(git show ...).

▲

masklinn 4 days ago | parent | prev | next [-]

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

▲

slang800 4 days ago | parent | prev | next [-]

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 4 days ago | parent | prev | next [-]

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.

▲

lucasoshiro 4 days ago | parent | prev | next [-]

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

▲

trenchpilgrim 4 days ago | parent | prev | next [-]

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

"What if the unit tests have bugs?"

▲

4 days ago | parent | prev [-]

[deleted]