The 'We are not bisecting' error appears when you run a git bisect command like 'git bisect good' or 'git bisect reset' without an active bisect session. This typically occurs when bisect was never started, already ended, or its state files were corrupted.
The "We are not bisecting" error in Git occurs when you attempt to run a bisect subcommand (like `git bisect good`, `git bisect bad`, or `git bisect reset`) but Git cannot find an active bisect session. Git bisect is a binary search tool that helps you find the commit that introduced a bug. When you start a bisect session with `git bisect start`, Git creates state files in the `.git` directory (specifically `BISECT_START`, `BISECT_LOG`, and refs under `refs/bisect/`) to track your progress through the commit history. If these state files don't exist or are corrupted, Git doesn't recognize that a bisect session is active and returns this error. This can happen if you never started a bisect session, if you already reset it, if you switched to a different repository, or if a system crash or manual deletion removed the bisect state files.
If you haven't started a bisect session yet, begin one properly:
# Start the bisect session
git bisect start
# Mark the current (buggy) commit as bad
git bisect bad
# Mark a known good commit
git bisect good <known-good-commit>You can also combine these in a single command:
# Start with bad and good commits in one command
git bisect start HEAD <known-good-commit>Once you've marked both a bad and good commit, Git will begin the binary search process.
Make sure you're in the same repository where you started the bisect:
# Check current directory
pwd
# Check if this is a git repository
git rev-parse --git-dir
# See if there are any bisect state files
ls -la .git/BISECT_* 2>/dev/null || echo "No bisect files found"If you're in a different directory or repository, navigate to the correct one.
Sometimes the BISECT_START file is missing but other bisect files remain. Check for leftover state:
# Check for any bisect-related files
ls -la .git/BISECT_*
# Check for bisect refs
git for-each-ref refs/bisect/If you see refs/bisect/ entries but no BISECT_START file, you have a corrupted state that needs cleanup.
If you're on Git 2.44 or newer, git bisect reset can clean up orphaned bisect state:
# Check your Git version
git --version
# Try reset with a specific ref to force cleanup
git bisect reset HEADThe trick is that git bisect reset <ref> skips the BISECT_START check and performs cleanup anyway.
For older Git versions or stubborn cases, manually remove the bisect state files:
# Remove all bisect state files
rm -v .git/BISECT_*
# If in a worktree, files might be in a different location
# Check: .git/worktrees/<name>/BISECT_*After removing these files, Git will no longer think a bisect is (or should be) in progress.
If there are stray refs under refs/bisect/, remove them:
# List bisect refs
git for-each-ref --format='%(refname)' refs/bisect/
# Delete each one
git for-each-ref --format='%(refname)' refs/bisect/ | xargs -r -n1 git update-ref -dAlternatively, you can remove them directly from the filesystem:
rm -rf .git/refs/bisect/If you're using Git worktrees, bisect state is stored per-worktree:
# List your worktrees
git worktree list
# For a worktree, bisect files are in:
# .git/worktrees/<worktree-name>/BISECT_*Make sure you're running bisect commands in the correct worktree, or clean up the worktree-specific bisect state.
Once you've cleaned up any stale state, start a fresh bisect session:
# Ensure clean state
git bisect reset 2>/dev/null || true
# Start new bisect
git bisect start
# Now mark your commits
git bisect bad HEAD
git bisect good v1.0.0 # or whatever known-good commit/tagGit will automatically check out a commit in the middle for you to test.
### Understanding Bisect Session Lifecycle
A git bisect session involves several state files in the .git directory:
- BISECT_START: Records the branch/commit where bisect was initiated
- BISECT_LOG: Contains the log of good/bad markings for replay
- BISECT_EXPECTED_REV: Tracks the expected revision during bisect
- BISECT_ANCESTORS_OK: Optimization flag for ancestry checking
- refs/bisect/: Contains refs for good/bad boundary commits
The git bisect reset command checks for BISECT_START to determine if a session is active. If this file is missing but other files exist (due to crash, manual deletion, or bug), you get a confusing state where the prompt may show "bisecting" but commands fail.
### Git 2.44 Fix (December 2023)
Prior to Git 2.44, git bisect reset would refuse to clean up if BISECT_START was missing, leaving users stuck with no easy cleanup path. Commit daaa03e (December 2023) fixed this by teaching git bisect reset to clean up orphaned state files and refs even when BISECT_START is gone.
### Automated Bisect with git bisect run
For repeatable bug hunting, use automated bisect:
git bisect start HEAD v1.0.0
git bisect run ./test-script.shThe script should exit 0 for "good" commits and 1-127 (except 125) for "bad" commits. Exit code 125 means "skip this commit" (useful for commits that don't compile).
### Alternative Terms
If you're finding a commit that fixed a bug (reverse bisect), use the newer terminology:
git bisect start --term-old broken --term-new fixed
git bisect broken HEAD
git bisect fixed v1.0.0This avoids confusion about what "good" and "bad" mean in different contexts.
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server