Re: git bisect code 125 - "WFT?"

Piotr Krukowiecki [off-list ref] 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?

On Wed, Mar 16, 2011 at 10:36 PM, Junio C Hamano [off-list ref] wrote:

Piotr Krukowiecki [off-list ref] writes:

quoted

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.

Of course if changing the meaning is out of option it's better to document
then not to document.

-- 
Piotr Krukowiecki

Am 3/16/2011 23:06, schrieb Piotr Krukowiecki:

On Wed, Mar 16, 2011 at 10:36 PM, Junio C Hamano [off-list ref] wrote:

quoted

Piotr Krukowiecki [off-list ref] writes:

quoted

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

-- Hannes

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

Am 3/16/2011 23:06, schrieb Piotr Krukowiecki:

quoted

On Wed, Mar 16, 2011 at 10:36 PM, Junio C Hamano [off-list ref] wrote:

quoted

Piotr Krukowiecki [off-list ref] writes:

quoted

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