Hi, On Sat, Jul 19, 2025 at 5:32 PM Begad Habib <begadhabib989@xxxxxxxxx> wrote: > > 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 When both one "good" and one "bad" commits have been specified, then Git starts bisecting, which means that you should then see something like: Bisecting: 0 revisions left to test after this (roughly 0 steps) [df357f37981b7f1e804684cc09842d02fd012146] Commit 2 - middle and Git should have checked out "Commit 2 - middle", so HEAD should point to that commit. By the way it could help if you could show git's output when giving steps to reproduce like this. > git bisect skip HEAD~1 This will "skip" the commit before the current one, so "Commit 1 - good", which is already marked as "good". I guess this is not what you want. You wanted to skip "Commit 2 - middle", right? In this case `git bisect skip` (without any additional argument) to skip the current commit is enough. > Observed Output (Note that I see the output you show below only when "Commit 2 - middle" is skipped by the previous command above.) > There are only 'skip'ped commits left to test. > The first bad commit could be any of: > <commit 1> > <commit 2> I am not sure if <commit 1> and <commit 2> here refer to "Commit 1 - good" and "Commit 2 - middle" respectively or not. To avoid confusion, you might want to be explicit about what they refer to. Anyway when I try to reproduce, I see the hashes of "Commit 2 - middle" and "Commit 3 - bad" which is what I expected. > We cannot bisect more! > > This output is a bit confusing, since the bad commit was already > identified (HEAD, i.e., Commit 3), Git's output talks about the "first bad commit" not the commit currently marked as "bad". "first bad commit" has a special meaning. It means the first commit in the commit history that would be "bad" if all the commits could be tested (and thus no commit was skipped). > and the middle one was explicitly > skipped. Yeah, but that doesn't mean it couldn't be the "first bad commit". The git bisect documentation about "skip" says: "However, if you skip a commit adjacent to the one you are looking for, Git will be unable to tell exactly which of those commits was the first bad one." This is what happens here, and that should be expected. Git cannot tell between "Commit 2 - middle" and "Commit 3 - bad" which one would be the first bad one if all the commits could be tested. > Including the good commit (Commit 1) in the potential bad > list could mislead users into thinking it might be faulty. That's not what I see. I don't see the hash of "Commit 1 - good" listed there when I try to reproduce. But again your reproduction steps have some issues, see above. So I am not sure I reproduced the issue you saw or not. > Question > > Is this the expected behavior for skipped commits? Or could the output > be more accurate by excluding commits already marked as good? Commits already marked good should be excluded but maybe if you mark them as both "good" and "skip"ped there could be some issues. Anyway we would need better reproduction steps to be able to debug this. And yeah I also tried to mark both "Commit 1 - good" and "Commit 2 - middle" as "skip"ped, and `git bisect` still seems to work correctly to me, especially it still say that it cannot tell between "Commit 2 - middle" and "Commit 3 - bad" (without showing the hash of "Commit 1 - good"). > Thanks for your time and the amazing work you all do on Git 🙏 Thanks for the kind words!
