Re: git bisect for reachable commits only

From: Oleg Taranenko <olegtaranenko@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git <git@vger.kernel.org>
Subject: Re: git bisect for reachable commits only
Date: Fri, 5 Aug 2016 01:29:32 +0200	[thread overview]
Message-ID: <CABEd3j9J-fULWygXnSR0oY9g_m0vWukjAE4aeb6QmiQ1u5FOyw@mail.gmail.com> (raw)
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:
> 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

>> 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.