Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

>>
>> First bisect should ask you to test merge bases only if there are
>> "good" commits that are not ancestors of the "bad" commit.
>
> Please note that this is a stateless job. The only "state" I have is the
> branch name.
>
> So when something goes wrong, I have *no* indicator what is a known good
> state.

> The strategy I implemented was to use knowledge about the branches and
> their relations. So when there is a bug in `pu`, the script first tests
> whether the same test passes in `next`. And if it does, that is my
> known-good state.
>
> In the meantime, I cheat and mark all merge-bases as known-good, too. But
> that is by no means a correct assumption: sometimes Junio decides to base
> a patch on top of a really ancient commit, one that may be broken on
> Windows. So there you are, I cannot win, I just tried to implement
> something that works reasonably well, most of the time. It still takes way
> too long.
>
>> Second yeah there is probably an old bug in bisect there. In theory in
>> most cases bisect should ask you to test only one merge base, as:
>>
>> - if the merge base is "bad", it means that the bug has been fixed
>> between the merge base and your "good" commit, and bisecting will
>> stop,
>> - if the merge base is "good", it means that all the merge bases that
>> are ancestor of this merge base are also good, so there is no need to
>> test them
>
> That is not necessarily correct. If there are two merge bases, one may be
> broken, and then that one is the first bad commit.