Re: git bisect code 125 - "WFT?"

From: Jeff King <peff@peff.net>
Date: Mar 17, 2011, 07:27 UTC
Message-ID: <20110317072723.GH11931@sigill.intra.peff.net>
In-Reply-To: <4D81B04A.1010802@viscovery.net>

On Thu, Mar 17, 2011 at 07:55:06AM +0100, Johannes Sixt wrote:

Show 23 quoted lines

> Am 3/16/2011 23:06, schrieb Piotr Krukowiecki:
> > On Wed, Mar 16, 2011 at 10:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> Piotr Krukowiecki <piotr.krukowiecki@gmail.com> writes:
> >>
> >>> Opinions? Would it be possible to change the meaning of the codes now
> >>> (in 1.8.0)?
> >>
> >> How about just documenting why it is a bad idea to use 126 or 127 as you
> >> found out somewhere, and stopping there, iow, without changing the code to
> >> use 126/127 that we consider it is a bad idea to use and avoided using so
> >> far?
> > 
> > Documenting it won't help. If you get 126 code, you won't know if user
> > returned it to mark the code as bad, or if bash returned it to say
> > that it can't
> > execute a command.
> 
> Huh? Why should the user's script return 126 or 127, particularly if the
> documentation says "don't do that"? Moreover, any decent (shell)
> programmer will know that these two values are reserved by POSIX for
> particular purposes (they are _not_ specific to bash):
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

I think the argument is not that the user would want to return those codes, but that we can protect a poorly written test script from itself by including those exit codes in the list of "indeterminate result" codes.

IOW, currently this:

  git bisect run 'make && ./test-pogram'

will happily generate a bogus bisection. And obviously that's a trivial example, but one can imagine a much larger script with a missing command in it.

There are two problems with that argument that I see, though:

  1. It only protects some very specific cases, and they're not even
     interesting cases. Say your bisection runs a test script that looks
     like this:

       cmd1
       missing-cmd
       cmd2

     we _still_ won't see it as an indeterminate result, because the
     missing cmd's exit code is lost. So you would have to write:

       cmd1 &&
       missing-cmd &&
       cmd2

     but that doesn't really help much. If you are going to be that
     careful, what you really want is something like:

       cmd1 || exit 125
       missing-cmd || exit 125
       cmd2 || exit 125
       some-final-command-to-check-the-state

     So it can help, but I don't think it really helps in real-world
     cases.

  2. If we do detect such a mishap, I'm not sure that "indeterminate
     result" is necessarily the best result, as that will just keep
     trying more and more commits without success. It is more likely a
     sign of a poorly written test script, and the best thing we could
     do is die and say "your test script looks buggy".

-Peff