search

Found

info Overview

Find how many git bisect steps locate a bug in N commits via ceil(log2(N)), estimate total time from your build duration, and see each binary halving.

📘 How to Use

  1. Enter the number of commits you plan to bisect through
  2. Optionally set the known good and bad positions to narrow the range
  3. Enter the time one build or test takes per step

Git Bisect Steps Calculator

Position of the last commit known to work. Older commits sit closer to 0.

Position of the newest commit known to be broken. Leave blank for the latest (HEAD).

sec

Results

Bisect Steps
0
Commits in Range
0
Time Estimate
0s
Binary Search Convergence

※ Formula: steps = ⌈log₂(n)⌉ = 0

grid_view Related

Article

Git Bisect Steps Calculator | Estimate rounds and time to find a regression

Before you start a git bisect session, it helps to know how many good/bad answers you will have to give. Enter the number of commits and this tool returns the required steps as ceil(log2(N)), an estimated total time based on your per-build duration, and a step-by-step view of the binary search halving the range.

💡 About this tool

git bisect runs a binary search between a commit you know was good and one you know is bad, isolating the offending commit in O(log N) time. Across 1000 commits, checking one at a time could take up to 1000 builds; binary search needs only about 10.

The friction is usually up front: when CI takes several minutes per run, you want to know whether you are signing up for 7 rounds or 20 before you commit to the session. This calculator derives the step count from your commit range with ceil(log2(N)) and multiplies it by your per-step build time to estimate the total. If you already know roughly where the last good and first bad commits sit, set those positions and the search range shrinks accordingly, lowering both the step count and the time. It is a quick way to see how much narrowing the range actually pays off.

🧐 Frequently Asked Questions

How is the step count calculated? It takes the number of commits in the range as N and returns ceil(log2(N)). Each bisect step halves the remaining range, so this is how many splits it takes to drive N down to a single commit. When N is 1, the result is 0 steps because there is nothing left to divide.

Do I have to enter the good and bad positions? No. Leave them blank and the tool treats the good commit as the start of history (0) and the bad commit as the latest (HEAD), using the full commit count as the range. Filling them in restricts the search to that interval, which lowers the steps and the time estimate.

How accurate is the time estimate? It is a plain multiplication of step count by your per-step time. Feed it your average build or manual-test duration and you get a ballpark figure; it does not account for CI queue waits or pausing and resuming the bisect. Treat it as a sense of scale before you begin.

Does git bisect run change the number of rounds? No. git bisect run <script> only automates the good/bad verdict for each step; the binary search still performs the same number of divisions. Whether you answer by hand or let a script answer, the step estimate holds.

📚 Why binary search stays fast

The word "bisect" means to cut in two. Halving the range each round means the candidate set drops by half every time, so reaching a single commit from N takes only "how many times you can divide N by 2 until you hit 1" — that is log2(N). Doubling the commit count adds just one extra step: roughly 10 rounds for 1000 commits, about 20 even for a million. That near-flat growth is exactly why bisect stays practical on huge repositories. One caveat: commits that fail to build can be set aside with git bisect skip, but as skips pile up there are fewer clean splits available, so the real round count can drift slightly above the theoretical value.