Begad Habib <begadhabib989@xxxxxxxxx> writes: > 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 > --- Thanks for a report. CC'ing the primary author of "git bisect skip" and showing of skipped ones for their thoughts. > 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
