From: "Theodore Tso" <tytso@mit.edu>
To: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Cc: "Steven Rostedt" <rostedt@goodmis.org>,
"Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
"Jonas Rebmann" <kernel@schlaraffenlan.de>,
"Ricardo B. Marlière (SUSE)" <ricardo@marliere.net>
Subject: Re: FYI, git output messages are being used by other tooling
Date: Tue, 20 Oct 2026 18:48:36 -0400 [thread overview]
Message-ID: <atfmYYtUii4gWIIH@mit.edu> (raw)
In-Reply-To: <83c59078-f6f1-456a-a99b-688eaf56bab0@app.fastmail.com>
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
This results in an RPC call to the Lightweight Test Manager (ltm),
which is a micro VM running in Google Compute Engine. If there isn't
a Kernel Compile Service (kcs) VM already launched, the ltm VM will
launch a much larger build VM. Once the kcs VM is ready, the bisect
request is then forwarded to the kcs VM. The kcs VM will check out
relevant repo, run "git bisect start", and will do the build. Once
the kernel is built, it then sends a RPC to the ltm VM, and the ltm VM
will launch one or more test VM's (in above example, one for the
ext4/4k config, and one of the ext4/1k config). The ltm VM will
monitor the serial console of the systems under test, so if the kernel
hangs, the ltm VM can force reboot a failing VM and either continue
with the next text (if there is more than one test that is being run).
If we are doing a bisect, then the ltm VM will send a bisect update to
the kcs VM via an RPC.
This architecture allows multiple biseccts or test watches to be
managed by a single ltm VM and (if necessary the kcs VM --- the kcs VM
will shut itself down if it's not needed to save on cloud costs).
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.
Cheers,
- Ted
P.S. For more information about how my test appliance works, and the
other features/functionality of the ltm VM, see [1] and [2].
[1] https://thunk.org/gce-xfstests
[2] https://github.com/tytso/xfstests-bld/blob/master/Documentation/gce-xfstests.md
next prev parent reply other threads:[~2026-10-20 22:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 18:10 Steven Rostedt
2026-10-20 18:37 ` Junio C Hamano
2026-10-20 18:52 ` Steven Rostedt
2026-10-20 19:09 ` Theodore Tso
2026-10-20 19:23 ` Steven Rostedt
2026-10-20 19:28 ` Kristoffer Haugsbakk
2026-10-20 19:33 ` Steven Rostedt
2026-10-20 22:48 ` Theodore Tso [this message]
2026-10-20 18:44 ` Kristoffer Haugsbakk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=atfmYYtUii4gWIIH@mit.edu \
--to=tytso@mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kernel@schlaraffenlan.de \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ricardo@marliere.net \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®