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

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Mar 13, 2014, 17:19 UTC
Message-ID: <5321E8A7.3080907@alum.mit.edu>
In-Reply-To: <xmqqmwgvmfpk.fsf@gitster.dls.corp.google.com>

On 03/12/2014 07:31 PM, Junio C Hamano wrote:

Show 12 quoted lines

> Jacopo Notarstefano <jacopo.notarstefano@gmail.com> writes:
> 
>> On Mon, Mar 3, 2014 at 7:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> I think you fundamentally cannot use two labels that are merely
>>> "distinct" and bisect correctly.  You need to know which ones
>>> (i.e. good) are to be excluded and the other (i.e. bad) are to be
>>> included when computing the "remaining to be tested" set of commits.
>>
>> Good point. Yes, this isn't viable.
> 
> But if you make them into --no-longer-X vs --still-X, then it will
> be viable without us knowing what X means.

Yes, but who wants to type such long and inelegant option names?

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.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/