Is it possible to give `git bisect` a set of invalid commits to always skip?

Question

On long project, there can be a whole bunch of commits it's not worth trying during bisection e.g.

• commits which are known to be broken
• commits which are otherwise part of a PR not guaranteeing validity

The second one can mostly be handled by using bisect --first-parent though it requires remembering to use it, but the first one is more of an issue.

A script for bisect run can provide the feature, but then that needs to be a meta-script which either runs a sub-script (for the bisect run case) or acts as a shell taking old/new/skip commands to pass them along when a commit should be included.

Answer 1

Create a file, somewhere, e.g. bisect.blacklist with a list of the bad commits like this:

git bisect skip bef63087981a1033239f664e6772f86080bdec44
git bisect skip 72d1195b9b3919d1468d688909985b8f398c7e70
git bisect skip aef63087981a1033239f664e6772186080bdec3e

Then whenever you start bisecting with git bisect start, also run

git bisect replay bisect.blacklist

After that you should be able to bisect normally (be it by hand or by script), with git bisect already knowing to skip those commits.

If those commits are generally broken when it comes to bisecting, you could also track that file in git for extra convenience.

Hint: If you add git bisect start at the start of the blacklist file, then you don't have to run it manually before the replay command.

Answer 2

Have your bisect run script check for your known invalid revisions and exit with 125:

#!/bin/sh

grep -qxF "$(git rev-parse HEAD)" /path/to/invalid-revisions.txt && exit 125

# your real script here, or source/call your real script

/path/to/invalid-revisions.txt would contain one full commit hash per line. grep -qxF matches only full lines with the exact fixed string as provided, but in quiet mode. git rev-parse HEAD gives you the full commit hash of the commit currently being tested by bisect.

The logic to detect invalid commits can be as simple or as complicated as you need. You can check the content of the working tree, the build status, the commit message, the author, anything really.