Project

General

Profile

Actions

Task #1263

closed

Change bibisect behavior to prevent wasted time

Added by Joel Madero almost 9 years ago. Updated over 8 years ago.

Status:
Rejected
Priority:
Normal
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Tags:

Description

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.

Thanks

Actions #1

Updated by Joel Madero almost 9 years ago

  • Assignee set to Robinson Tryon
Actions #2

Updated by Christian Lohmaier almost 9 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....

Actions #3

Updated by Florian Effenberger almost 9 years ago

  • Status changed from New to Feedback

Can you give some feedback on that, Joel? Thanks! :-)

Actions #4

Updated by Florian Effenberger almost 9 years ago

  • Tracker changed from Feature to Task
Actions #5

Updated by Florian Effenberger over 8 years ago

  • Status changed from Feedback to Rejected

Having checked, it seems bibisecting is indeed working as intended, so rejecting this ticket.
Joel, if there are further questions, feel free to poke me. ;-)

Actions

Also available in: Atom PDF