From: Olliver Schinagl <oliver@schinagl.nl>
Date: Thu, 28 Mar 2024 08:01:03 GMT
Subject: Re: Allow git bisect to auto-skip
Message-ID: <e94be8ec-87aa-4703-b6bf-b37dd4919752@schinagl.nl>
In-Reply-To: <xmqqfrwb1nr8.fsf@gitster.g>

On 27-03-2024 20:24, Junio C Hamano wrote:
> Olliver Schinagl <oliver@schinagl.nl> 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.