Change bibisect behavior to prevent wasted time
I'm not entirely sure how bibisect works but I don't think it's as efficient as it could be.
The best bet would be that the first test is always the oldest commit, and the second commit always be the latest commit in the package.
The only time a third (and continuing) test would be needed is if the bug is not present in the first (oldest) and is present in the second (lastest).
Currently the issue is that you have to do an entire bibisect (8-12 checks) even if the bug isn't present ever in the bibisect package or is inherited from OOo.
What should happen:
1. Present in the oldest pull (first test) - bibisect should spit put "this bug is inherited from OOo"
2. Not present in oldest pull but present in second (newest) - full test required to bibisect
3. Not present in 1st or 2nd pull - no need to continue, bibisect should state "this bug was introduced during the commit range of this bibisect package"
If we hope to continue moving towards more bibisecting - ideally bibisecting every single bug - this will save a ton of time.
Updated by Christian Lohmaier over 8 years ago
I don't get the problem.
Yes, bibisect always works by checking whether the problem occurs in the given range.
Whether you check the newest commit first (whether you can reproduce it there) or the oldest (whether it is a regression that is within the bibisect range, or older and thus not bibisectable with the current repo) doesn't really matter.
Why do you get the idea that you have to do an entire bibisect ? This isn't even possible.
If the problem occurs in both oldest and newest, i.e you flag oldest and latest as bad, git bibisect will not even start, as it doesn't have a range to test (you always need both a "good" and a "bad" commit.
Same if it doesn't occur in either.
A bisect always works from the full range, to half the range, to half of that half, to half of the half of the half....