If the target is misbehaving and some changes unlock others,
then in general bisect is going to have a hard time and can fail
to identify the problem. It will usually say "target fails inconsistently".
One robustness improvement we can make is to use more bits than
necessary for exclusions, which reduces the chances of accidentally
excluding changes that simply didn't trigger this time around but
might still be part of a bug later. To do this, we calculate the minimum
number of bits needed to distinguish all the =y and =n changes
observed, round up to a number of hex digits, and then add another
digit for good measure.
Change-Id: I02354f281370806c3eb4d85911a6ca92fcfcae05
Reviewed-on: https://go-review.googlesource.com/c/tools/+/494276
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
I wasn't thinking of this package as an exported library,
but of course it is, so it should go through proposal review.
Moving to internal until that happens.
Change-Id: Ic8abbe5f6530d5d6201114c1799e26d604f3dd64
Reviewed-on: https://go-review.googlesource.com/c/tools/+/492976
TryBot-Bypass: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Russ Cox