Re: git bisect for reachable commits only

From: Oleg Taranenko <olegtaranenko@gmail.com>
Date: Aug 4, 2016, 23:29 UTC
Message-ID: <CABEd3j9J-fULWygXnSR0oY9g_m0vWukjAE4aeb6QmiQ1u5FOyw@mail.gmail.com>
In-Reply-To: <xmqqinvidgyo.fsf@gitster.mtv.corp.google.com>

On Tue, Aug 2, 2016 at 11:00 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> Oleg Taranenko <olegtaranenko@gmail.com> writes:
>
>> First, assuming the common ancestor is GOOD based on the fact that
>> some descendant given as GOOD is pretty bad idea.
>
> What you claim is fundamentally incompatible with the way "bisect"
> works as a O(log(n)) operation.  It is likely that your definition
> of Good for the purpose of your bug-hunting needs to be rethought if
> you want to take advantage of "bisect".

Without context it sounds a bit silly, agree. Context was, maybe not explicit stated, based on previous discussion:

If we looking in direct path G..B, of course bisect should show its power O(log(n)); BUT, assuming that any predecessor (G~1/G~2...)...is good if this commit G~n has direct path to B, but not via G, (as git does now) is wrong. This is my concern. Ever G~1 may have not feature we are looking for, then we must treated it as BAD in current git bisect session. To be sure we require additional evidence and just opening a new bisect roundrips in case G~n is GOOD. If G~n confirmed as BAD, we need to stop looking in this path (no need to find transition BAG -> BAD) and switch to another possible common ancestor (or next octopus parent) In merge-based development (opposite to rebased one) this can happen very easy

Show 7 quoted lines

>> I have another request to get git bisect more user-friendly, regarding
>> rolling back last step or steps, if accidentally 'git bisect bad' or
>> 'good' was wrong entered, but I think it worth for another thread.
>
> Are you aware that you can check $GIT_DIR/BISECT_LOG and replay it
> to recreate any previous state of the bisection?  That would
> probably help.

git bisect log / replay is not convenient. First we need to find place where to keep log file (not forget its name), then edit it. If I'm not sure how many steps I did a mistake the troubles doubles, What are obstacles to implement git bisect back ? or git bisect back --steps=2 I don't think it will be significant change in code.

It would be a great help especially if hunting in multiply logically loose-coupled repos. Say searching bug in application, possible caused elusive changes on several dependent libraries.