On Thu, Mar 17, 2011 at 07:55:06AM +0100, Johannes Sixt wrote: > Am 3/16/2011 23:06, schrieb Piotr Krukowiecki: > > On Wed, Mar 16, 2011 at 10:36 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> Piotr Krukowiecki <piotr.krukowiecki@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html