On 24-03-2024 19:34, Junio C Hamano wrote:
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.
I think you understood what I failed to properly explain :)
To come up with an RFC, I was trying to study the git code, and while
some things are quite readable, others are a bit complex.
After some poking, I was thinking of using `find_bisection()`, or rather
`do_find_bisection()` but got lost there.
What made sense initially was, that in `find_bisection()` there is a
simple for loop that goes over the list of commits to count them. But
writing this down, I realize the list of commits is already there in
`struct commit_list *list`, so I should probably go find out where the
list is being created!
Anyway, want I was thinking of, based a key somewhere in the message
body (GIT_BISECT_SKIP=1 for example), mark the commit in the list to be
skipped, as `git bisect skip` would. This so the skipped commit actualyl
ends up on the list of skipped commits (`refs/bisect/skip-*`).
But being a bit lost, it would be nice to get some directional pointers.
Is this even possible? What is the easiest way to get the message from
the `struct commit_list *list` item, are there helpers to parse the
message at all?
Thanks,
Olliver
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.
