From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=18.9.28.11 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792536614; b=llHZvl3e1VGDbHgykPKhMvsIVhQeq8U8Al3FKv8+AQEhkmsplSylUM5d3wGGmjJ8zUqu hiobdtYE2PULxgkPSzz6K8d4uaYFQLIbCGJCzCSsd2WKWfmIHdiaw6ByJ+kEhuFAzkUOj XYSc4y8q32bGK2bh6b8Pu43Jeqnt4HOVn/kqeE05stiNaLTAT9BaxvUzakDnJ5Snqufab ZVJyjHzKhyc/ptmDqTV5iwlVpeFo9sqyGF7pIlpIGSX8480qN22wfe3wKN3nF/vCO2+m3 qDPlkaG4FY48cGCHe3KkII2PFIcuxbTlroiMQd/F15cgMYgXfyeGgzEycqVImSl8fJw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792536614; h=DMARC-Filter:Received:DKIM-Signature:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=oZiXrRKvQcXJbnmZKNbeBglyOf7giCIx7g21DfvxHeM=; b=JhbEhmtG1dgOUeGtHD0c6ZW67EcNAbFaThN7/cvnVyXz0OVVev7HHdrFAQ6rJ19WZZmu tg1jEiRaunUKStCiCBD57gerdHpqLsCkf6308keD87QYFcJLtWVj2PEdvw46YCtcWvK4O maoAtIpYrw2OiVaHti+Y0dF+gy0+ss19o/bMYfvElAP2AMGFl3q1moMJq1dj5aCqFV/aE HK0eLBXr3lJuHxKGE7S0RlsBXRjBonhDhs5PB5H0OX4BrTM/mpSFk/Y8GOJ7cYp3GxoBj ZuMxSbXpezjqR1HYQpgcwo2UVE1Xwa951fj15Lh2FPlQDmrpCLs3JPmgUkiHokRvQ/Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=KVDCNzG4; arc=none smtp.remote-ip=18.9.28.11 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5A3B606A33B for ; Tue, 20 Oct 2026 22:50:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org C5A3B606A33B Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=mit.edu header.i=@mit.edu header.a=rsa-sha256 header.s=outgoing header.b=KVDCNzG4 Received: from macsyma.thunk.org (pool-173-48-113-115.bstnma.fios.verizon.net [173.48.113.115]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 69KMnbMs016711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Oct 2026 18:49:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1792536580; bh=oZiXrRKvQcXJbnmZKNbeBglyOf7giCIx7g21DfvxHeM=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=KVDCNzG4S3KuvOFjvzAKI2mVLHr+XqNSBP/1MyhAZyTHWdXKlM+d1ClZw2C2IJug8 HYBcBAuywcR7D/JgGFztfETkJ4ndtAyX6+OpzmG12NxJPtRUFs9IYEuj8kEiIooxCe VVIQyU+KBG3XxP1fye9bt5PeZAVZaGWGkBFV+pd+opyQ9m3Pcky5qq1KBCwuAATnnW +G1vcDGAjUU3OZFODM2ijPhuYv4iGLe+j2p0Ifkx8QxdmODAsSfx9T8XK++wSPgOuw 8gEyG7gWlLSvCRI7idTscavVdMALKTcRfQ+NcmOcuxIb8aycbXaKSW1mgZ5mICBlul j4mmFiS/9Pc3A== Received: by macsyma.thunk.org (Postfix, from userid 15806) id 0A5BE21C98B6; Tue, 20 Oct 2026 18:48:37 -0400 (EDT) Date: Tue, 20 Oct 2026 18:48:36 -0400 From: "Theodore Tso" To: Kristoffer Haugsbakk Cc: Steven Rostedt , Junio C Hamano , git@vger.kernel.org, LKML , Jonas Rebmann , Ricardo =?utf-8?B?Qi4gTWFybGnDqHJlIChTVVNFKQ==?= Subject: Re: FYI, git output messages are being used by other tooling Message-ID: References: <20261020141011.0015d172@gandalf.local.home> <20261020152354.165ad128@gandalf.local.home> <83c59078-f6f1-456a-a99b-688eaf56bab0@app.fastmail.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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