Am 18.02.2017 um 00:21 schrieb Stephan Beyer:
On 02/17/2017 11:29 PM, Alex Hoffman wrote:
* 7a9e952 (bisect bad) <BAD>
|\
| * 671cec2 <BAD> <--- expected
| |\
| * | 04c6f4b <BAD> <--- found
* | | 3915157 <GOOD>
|\ \ \
| | |/
| |/|
| * | f4154e9 (bisect good) <GOOD>
| * | 85855bf <BAD>
| |/
* | f1a36f5 <BAD>
|/
* 1b7fb88 <BAD>
The <BAD> and <GOOD> markers are set by your definition of what good and
what bad commits are.
[...]
In other words: bisect assumes that your repo is usually in a good state
and you have a commit that changes it to a bad state. In your case you
have a repo that is in a bad state and you have a commit that switches
it to a good state and later you merge a bad-state branch and you have a
bad state again. It is not made for that use-case, I think.
Correct. The assumption of bisection is that there is only one
transition between GOOD and BAD. By violating that assumption, anything
can happen.
-- Hannes
