Hi Git developers, I've been analyzing the behavior of `git bisect` when dealing with skipped commits and noticed what might be an unexpected result. I wanted to share a minimal reproduction to understand whether this is intended behavior. -- ## Environment - Git version: 2.43.0 - OS: Ubuntu 22.04 --- Steps to Reproduce ```mkdir bisect-bug-test && cd bisect-bug-test git init # Commit 1 – good echo "good" > file.txt git add file.txt git commit -m "Commit 1 - good" # Commit 2 – skipped echo "middle" > file.txt git add file.txt git commit -m "Commit 2 - middle" # Commit 3 – bad echo "bad" > file.txt git add file.txt git commit -m "Commit 3 - bad" # Start bisect git bisect start git bisect bad git bisect good HEAD~2 git bisect skip HEAD~1 Observed Output There are only 'skip'ped commits left to test. The first bad commit could be any of: <commit 1> <commit 2> We cannot bisect more! This output is a bit confusing, since the bad commit was already identified (HEAD, i.e., Commit 3), and the middle one was explicitly skipped. Including the good commit (Commit 1) in the potential bad list could mislead users into thinking it might be faulty. Question Is this the expected behavior for skipped commits? Or could the output be more accurate by excluding commits already marked as good? Thanks for your time and the amazing work you all do on Git 🙏 Best regards
