From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 24 Mar 2024 18:34:26 GMT
Subject: Re: Allow git bisect to auto-skip
Message-ID: <xmqq8r27sclp.fsf@gitster.g>
In-Reply-To: <CAP8UFD2DhkmVias+RfMESJz9Z-rKKHWHB+MFHcDb9QLO16TOhg@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> writes:

> Also, how much better would this be compared to tracking  "git bisect
> run" scripts in the repo, even if they have to be copied somewhere
> else before they are launched? I wonder about this because writing the
> conditions that decide whether the current commit is good or bad might
> not be so easy either. So if the goal is to simplify things for users,
> then simplifying all the way by providing example scripts with
> comments about how they could be customized might be even better.

If we are driving our bisection session via "bisect run" script,
computing the condition that we need to skip in the script is the
most natural and obvious thing to do, but the way I guessed (because
it was not explicitly written down) what the OP wanted was a way for
bisect_next() called after even a manual "git bisect (good|bad)" to
automatically skip certain set of commits.  Because there are cases
where you have to be testing manually and cannot afford to write
"bisect run" script, giving a manual bisection a way to compute if a
commit need to be skipped may be worth having, and that was where my
"git bisect --skip-when <script>" came from.  It would not be
necessary if you are doing "bisect run", which can dynamically tell
if the commit is untestable.  And if the user is going to decide
after manually testing the one that is suggested, it is not useful
either, as the point would be to avoid even asking to test ones that
need to be skipped.  So it is likely that the set of commits that
need skipping is known a-priori before the bisect session even
begins.  The end user experience may look like:

 * "git bisect start" takes "--skip-when <script>" and remembers it,
   together with other options "start" can take (like <good>, <bad>,
   <terms>, <pathspec>).

 - If <good> and <bad> are already given upon "start", the command
   may check out a revision and ask you to test.

 * Every time the command checks out a revision to be tested by the
   user, the command guarantees if it satisfies the --skip-when
   condition (and internally doing "git bisect skip").

 * Otherwise the interaction between the user and the session is
   exactly the same as usual.