Christian Couder <christian.couder@xxxxxxxxx> 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.
