Re: FYI, git output messages are being used by other tooling

["Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com>]

On Wed, Oct 21, 2026, at 00:48, Theodore Tso wrote:
> On Tue, Oct 20, 2026 at 09:28:10PM -0500, Kristoffer Haugsbakk wrote:
>> > Where returning 0 means the bad commit has been found.
>> > Otherwise it keeps looping.
>>
>> Is this different from git bisect run?
>
> "git bisect run" isn't always the best way to manage a bisection.  For
> example, I might run a command like:
>
>    gce-xfstests ltm -c ext4/4k,ext4/1k  generic/245 --repo stable-gc.git \
>        --bisect-good v6.18.57 --bisect-bad queue/6.18
>
>[snip]

Thanks for the example. :)

>
> So yeah.  Sometimes "git bisect run" isn't really enough, and it would
> be useful to have a way for programs to be able to call other "git
> bisect" subcommands, and have a standardized way to get the results
> from the command without having to just parse the output and be
> dependant on the precise format of the human-readable output.

Yeah, I don’t know about git-bisect(1) subcommands but the `git rev-list
--bisect*` options showed some promise when I tried them.[1] But the
most useful property turned out to be the most annoying thing to figure
out for me: how to simply query for whether we have found the first bad
commit yet or not.

But maybe that was because I botched the bad/good setup.

† 1: Like for `--bisect-vars`: if it turns out that it is *missing*
     some useful vars then those could be added without worrying about
     backwards compatibility.