On 27-03-2024 20:24, Junio C Hamano wrote:
Olliver Schinagl <oliver@xxxxxxxxxxx> writes:
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-*`).
I think it is very unlikely that we'd adopt any hardcoded scheme
that allows only one supported way of marking commits as not to be
tested. Certainly not the kind that the committer is forced to know
the commit must be skipped during a bisection session before
creating the commit.
My goal is to make things work as automagically as possible, without
special tooling or scripts. This to make the barrier for entry as low as
possible. E.g. if someone says 'could you please bisect this for me',
things should just work.
Having said that, I also realize that the use-cases where a commit
message would be enough are limited. There's only a very rare cases
where it is known before hand a commit will break bisect.
The `GIT_BISECT_SKIP=1` would obviously be configurable, so it could be
set on a per-repo level, with a sane default, and probably wiser to use
`git commit --skip-bisect` to make use of said flag.
Having said all that, right now, I'm just exploring how things work, how
easy it would be, how logical it would be. So for thank you for bearing
with me :)
So I am not sure how much good it will do to
know that commit_list->item is a commit object on the list, or
calling repo_get_commit_buffer() on it would give the contents of
the commit object.
Knowing that commit_list->item->object.oid is the object name of
such a commit, and calling oid_to_hex() on such an object name
stringifies it, should be sufficient to write a new code that calls
out to a script specified via "git bisect --skip-when=<script>"
I had learned about `oid_to_hex()` already, and I am charmed by that
idea for sure. So much in that I'll look into this first. In the end,
both solutions could even be used as they are in nearly the same spot
I'd think.
Four things I lack right now. The first one I hope to have figured out
before your reply (but don't shy the reply).
1) What is the best way to parse the skip-when argument. I see
`bisect_start()` does arg parsing, but trying to see what 'the git way'
is to get the argument of the new flag.
2) Where to store the argument. `bisect_terms` is passed around
everywhere to hold the good and bad states, but with bisect doesn't pass
much of anything else around. Though `bisect_run` isn't storing
`command` either, and you do mention so I'll delve into that and see how
that maps into the `run_command()` API.
3) Using the `run_command()` API implies to do the check 'on checkout';
which was my first idea as well, but a) where does this happen? I have
not found this yet, though `bisect_run` might be more revealing here,
3) Using this approach, can I still do a 'regular' `git bisect skip` in
that the skip gets recorded (in refs/bisect/skip-*)? I think it would be
nice to see what was skipped.
Thanks,
Olliver
using the run_command() API to decide if the commit object should be
skipped, and if you do want GIT_BISECT_SKIP=1 in the log message,
your script given via --skip-when may be a single-liner:
#!/bin/sh
# usage: this-script $commit_object_name
# expected to exit with 0 when the commit should not be tested
git cat-file commit "$1" | sed -e '1,/^$/d' | grep GIT_BISECT_SKIP=1
Thanks.
