How to fix Some good revs are not ancestors of the bad rev in Git

GitINTERMEDIATEMEDIUM

This error occurs when Git bisect detects that the commit marked as 'good' is not an ancestor of the 'bad' commit. This typically happens when searching for a fix instead of a regression, or when good/bad commits are swapped.

What this error means

Git bisect uses binary search to find the commit that introduced a bug. For this to work, it requires that the "good" commit (where the bug doesn't exist) must be an ancestor of the "bad" commit (where the bug exists). This reflects the assumption that a bug was introduced at some point and persisted in all subsequent commits. Git's history is stored as a Directed Acyclic Graph (DAG), where each commit points to its parent(s). When you mark a commit as "good" and another as "bad," Git expects to traverse from the bad commit backward through the history to reach the good commit. If the good commit is not reachable by following parent pointers from the bad commit, Git cannot perform the binary search. This error commonly appears in three scenarios: you've accidentally swapped which commit is good vs bad, you're trying to find when a bug was *fixed* rather than introduced (reverse bisect), or you're working with a complex non-linear history where branches were merged in unexpected ways.

How to fix "Some good revs are not ancestors of the bad rev"

1Verify the commit order

First, confirm which commit is actually older. Check if the "good" commit is an ancestor of the "bad" commit:

bash

git merge-base --is-ancestor <good-commit> <bad-commit>
echo $?

If this returns 0, the good commit IS an ancestor of bad (correct order). If it returns 1, the commits are in the wrong order or on different branches.

You can also visualize the relationship:

bash

git log --oneline --graph <good-commit>..<bad-commit>

2Reset and swap good/bad if reversed

If you simply have the commits backwards, reset the bisect and start over with them swapped:

bash

git bisect reset
git bisect start
git bisect bad <formerly-good-commit>
git bisect good <formerly-bad-commit>

Remember: "good" means "the bug is NOT present" and "bad" means "the bug IS present." The bug should exist in the bad commit but not in the good commit.

3Use old/new terminology for finding fixes

If you're trying to find which commit *fixed* a bug (rather than introduced one), the traditional good/bad terminology is confusing. Git provides alternative terms:

bash

git bisect reset
git bisect start --term-old=unfixed --term-new=fixed
git bisect unfixed <older-commit-with-bug>
git bisect fixed <newer-commit-without-bug>

Or use the built-in old/new terms (Git 2.7+):

bash

git bisect reset
git bisect start
git bisect old <commit-where-bug-exists>
git bisect new <commit-where-bug-is-fixed>

Note: You cannot mix good/bad with old/new in the same session.

4Handle non-linear history with first-parent

If you have a complex merge history and want to bisect only the mainline commits (skipping feature branch commits), use the --first-parent option (Git 2.29+):

bash

git bisect reset
git bisect start --first-parent
git bisect bad HEAD
git bisect good <known-good-commit>

This restricts bisect to follow only the first parent at each merge, typically the mainline branch.

5Find the correct ancestor with merge-base

If your good commit is on a different branch, find a common ancestor that both branches share:

bash

git merge-base <good-commit> <bad-commit>

Use this merge base as your starting point:

bash

git bisect reset
git bisect start
git bisect bad <bad-commit>
git bisect good $(git merge-base <good-commit> <bad-commit>)

This ensures the good commit is in the ancestry path of the bad commit.

6Visualize the history to understand the DAG

Before starting bisect, visualize the commit graph to understand the relationship between commits:

bash

git log --oneline --graph --all --decorate | head -50

Or for a specific range:

bash

git log --oneline --graph <good-commit>...<bad-commit>

The three-dot syntax shows commits reachable from either commit but not both, helping you see if they're on divergent branches.

7Use git bisect run with proper term handling

When automating bisect with a test script, ensure your script correctly handles the terminology you're using:

bash

# For finding a regression (traditional)
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
git bisect run ./test-script.sh

# For finding a fix (custom terms)
git bisect start --term-old=broken --term-new=fixed
git bisect broken v1.0.0
git bisect fixed HEAD
git bisect run ./test-script.sh

The test script should exit with code 0 for "good/old/fixed" and non-zero for "bad/new/broken".

How to fix Some good revs are not ancestors of the bad rev in Git

What this error means

Typical symptoms

Common causes

How to fix "Some good revs are not ancestors of the bad rev"

Advanced notes

Related errors

Official resources & further reading