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
