Re: Possible git bisect behavior issue when skipping commits

[Junio C Hamano <gitster@pobox.com>]

Begad Habib <begadhabib989@gmail.com> 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