Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html