git:bisect

Git Bisect - Binary Search for Bug-Introducing Commits

Interactive git bisect workflow to find commits that introduced bugs using binary search.

Command

/git:bisect [mode] [commit-ref]

Arguments

• $1: mode - start|good|bad|skip|reset (optional, interactive if not provided)
• $2: commit-ref (optional, depends on mode)

Description

Git bisect uses binary search to efficiently find the commit that introduced a bug. Instead of checking every commit, it splits the commit range in half repeatedly, asking you to test each midpoint. This can find a bug in log(n) checks instead of n checks.

Workflow

Starting a Bisect Session

1. Pre-flight checks:

   • Check if bisect is already in progress: git bisect log
   • Check for uncommitted changes: git status --porcelain
   • If changes exist, warn user and suggest stashing

2. Gather information:

   • Ask for the "good" commit (where bug didn't exist)
     • Default: last tag or commit from 1 week ago
     • User can specify: commit hash, tag, branch name
   • Ask for the "bad" commit (where bug exists)
     • Default: HEAD (current commit)
     • User can specify: commit hash, tag, branch name
   • Calculate and show number of commits between good and bad
   • Estimate number of steps needed: ~log2(n)

3. Start bisect:

   git bisect start
   git bisect bad [bad-commit]
   git bisect good [good-commit]
   

4. Show first commit to test:

   • Display commit hash, date, author, message
   • Show which files changed: git show --stat <commit>
   • Provide clear instructions on what to test

During Bisect Session

1. Test current commit:

   • Ask user to test whether the bug exists
   • Provide clear instructions:
     • "Run your tests"
     • "Manually test the feature"
     • "Check the logs"
   • Wait for user feedback

2. Mark commit based on test result:

   • If bug exists: git bisect bad
   • If bug doesn't exist: git bisect good
   • If commit is untestable (won't build, etc): git bisect skip
   • Option to abort: git bisect reset