From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 6041D1F487 for ; Sat, 28 Mar 2020 19:14:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726325AbgC1TOx (ORCPT ); Sat, 28 Mar 2020 15:14:53 -0400 Received: from smtp.hosts.co.uk ([85.233.160.19]:8560 "EHLO smtp.hosts.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725807AbgC1TOx (ORCPT ); Sat, 28 Mar 2020 15:14:53 -0400 Received: from [92.30.123.115] (helo=[192.168.1.38]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1jIGux-000468-8E; Sat, 28 Mar 2020 19:14:51 +0000 Subject: Re: [RFC] Proposal: New options for git bisect run to control the interpretation of exit codes To: Stephen Oberholtzer , Christian Couder Cc: git , Christian Couder References: From: Philip Oakley Message-ID: <24c58c80-c274-6a64-051c-90329432b85d@iee.email> Date: Sat, 28 Mar 2020 19:14:51 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Sorry this is late. On 16/01/2020 02:40, Stephen Oberholtzer wrote: >> The above doesn't tell what happens if a status is both on the >> --old-status and on the --new-status lists... > No, the below does. > >>> * Otherwise, the command is treated as having experienced a fatal error, >>> and run will terminate with a nonzero exit status. >> ...so it seems that it is an error only when such a status code is >> actually received by `git bisect run`. >> >> Some people could argue though that `--new-status=0 --old-status=0` >> should be detected as an error as soon as `git bisect run` is >> launched. > There are a few reasons for not raising an error immediately: > - Such a check would not be free. While the example you gave is > simple enough, things can quickly get complicated. A generalized > version would have to check every single status from 0 to 255 > (that said, I can see some value in proactively checking 0 and 1 > before starting the run, just as a sanity check) > - If there _is_ an ambiguous exit code, it doesn't actually matter > unless it's actually encountered > - If the user makes such a mistake, the bisection doesn't go off the > rails; it just halts. Will such a mistake be _reported_ (suitable message) to the user? This would at least short circuit misunderstandings as to the reason for the halting of the bisect. > A simple 'git bisect good' or 'git bisect bad', > followed by another call to "run" with corrected options, will address > the issue. > Philip