Before moving on, a quick `git reset —-hard` will get back to a clean flip
1. Create new test (e.g. "spec/reproduce-bug_spec.rb")
2. Ignore it locally: `echo "spec/reproduce_bug_spec.rb" >> .git/info/exclude`
3. Run bisect (something like: `git bisect run rspec spec/reproduce-bug_spec.rb`)
If running the test gets more complex (e.g. installing dependencies as they might change travelling through history), I usually create a wrapper script (and ignore it) to bisect-run-it.
You could just copy that entrypoint into another untracked file, have its list include (or be only - quicker) the new untracked test file, and execute that instead of the normal one while bisecting.
$ git bisect [good|bad]
$ git cherry-pick new-test
$ ./run-the-test
$ git reset --hard HEAD^
$ git bisect [good|bad]
git bisect run --cherry-pick abc123 [....]
to do a regular bisect but at each step cherry picking the commit abc123
A feature I’m still missing is to bisect using a new test. That is, I have discovered a bug in the program that there is no test for, so I author a failing test. Now I want to find out when this failure occurred but I can’t bisect because even the previous commit is green as the test didn’t exist. It’s possible to work around by placing the test outside the repo root and bisecting with a script that “authors” the test (e.g copies the file) at each step, but it’s cumbersome and feels like something that could be possible to add to the bisect command, e.g an option to merge a commit (the new test) before testing each step of the bisect.