Re: An idea for "git bisect" and a GSoC enquiry

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 13, 2014, 18:47 UTC
Message-ID: <xmqqk3byhr55.fsf@gitster.dls.corp.google.com>
In-Reply-To: <5321E8A7.3080907@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 26 quoted lines

> It seems to me that we can infer which mark is which from the normal
> bisect user interaction.  At the startup phase of a bisect, there are
> only three cases:
>
> 1. There are fewer than two different types of marks on tested commits.
>    For example, maybe one commit has been marked "bad".  Or two commits
>    have both been marked "slow".  In this case we wait for the user to
>    choose another commit manually, so we don't have to know the meaning
>    of the mark.
>
> 2. There are two different types of marks, but no commits with
>    differing marks are ancestors of each other.  In this case, we pick
>    the merge base of two commits with differing marks and present it
>    to the user for testing.  But we can do that without knowing which
>    mark is "before the change" and which mark means "after the
>    change".  So just defer the inference.
>
> 3. There are two different types of marks, and a commit with one mark
>    is an ancestor of a commit with the other mark.  In this case, it is
>    clear from the ancestry which mark means "before the change" and
>    which mark means "after the change".  So record the "orientation" of
>    the marks and continue like in the old days.
>
> Of course, there are still details to be worked out, like how to tag the
> commits before we know which mark means what.  But that is just a
> clerical problem, not a fundamental one.

Yup, with an extra "state" kept somewhere in $GIT_DIR, we should in principle be able to defer the "value judgement" (aka "which one should be treated as a bottom of the range").

The first change that is needed for this scheme to be workable is to decide how we mark such an unknown state at the beginning, though. We assume that we need to keep track of a single top one ("bad", aka "no-longer-good") while we have to keep track of multiple bottom ones ("good").

There also is a safety valve in the current logic for transitioning from case #2 to case #3; when a common ancestor is marked as "bad" (aka "no-longer-good"), we notice that the original bisection is screwy in the sense that the user is seeing not just a single state flip that made something that used to be good into bad.

I am afraid that we may instead _silently_ decide that the user is trying to locate a state flip that made something that used to be bad (at the common ancestor) into good with the logic proposed above. From the point of view of the user who wanted to find a regression by marking one as "bad" and the other "good", running bisection whose semantics suddenly and silently changed into an opposite "where was it fixed" hunt would be an unpleasant and confusing experience. I do not know, without knowing the meaning of "slow" and "fast" (which implicitly tells us which way the user intends to bisect), how well we can keep that safety valve.

Other than that, I like the idea.