Mike Hommey <mh@xxxxxxxxxxxx> writes:
> On Mon, Jan 18, 2016 at 12:43:35AM -0800, Junio C Hamano wrote:
> ...
>> two). If you have three states, black/gray/white, that linearly
>> transitions states twice (i.e. one part of the history is
>> continuously black, and at one boundary it turns gray and continues
>> to be gray, until at another boundary it turns white and continues
>> to be white to the other end), you would still "bi"-sect to find
>> these two transition points....
>> ... Is that the kind of search you are talking about?
>
> Yes, it is. Somehow, I was thinking of the result once you're done
> bisecting, not the process itself of cutting history in two parts.
I am not sure what you meant by "Yes it is"; is the above (i.e. in a
history whose one part is painted continuously in black, one part
continuously in gray and the remainder in white where white and
black never touch, find the transition between black and gray and
the transition between gray and white) the kind of search you are
talking about? Judging from the remainder of your message, I had an
impression that you are solving a different problem where you want
to find transitions for N distinct traits (i.e. 2^N combinations,
not N distinct colors like black-gray-white).
> That being said, while I can do these things locally with my own
> scripts, as a user, I would have found it useful if git bisect (and
> especially git bisect run) would support this out of the box. The
> question remains whether it would be useful to more people than
> just me.
Hmm, sorry. For the two-trait example I gave (that can be extended
to N-trait), I can sort of see how the UI might look and I can say
it might be useful [*1*], but not with this, and especially that you
do not necessarily know all the traits whose transition points you
might be interested in a-priori--all of that makes the problem
definition fuzzy to me, and I cannot imagine what kind of user
interaction you would be envisioning to solve what kind of problem,
so I cannot even say it is a good idea or a bad idea.
[Footnote]
*1* I suppose a possible UI for the N-trait bisection might go like
this. You start from just a single trait (good for your test #1
passing, bad for your test #1 failing). You start with:
$ git bisect start
$ git bisect good A
$ git bisect bad Z
and Git would give you a commit (let's call it M) to test. You
test and find that test #1 passes, but at the same time you find
that test #2 does not pass. You do not know if test #2 passes
or fails at A nor Z. At this point, you would decide to call
"test #2 passes" as good2, "test #2 fails" as bad2. We now have
two independent traits (good/bad and good2/bad2), and mark M as
good and bad2:
$ git bisect add-trait new/old/unknown=good2/bad2/unknown2
$ git bisect state good bad2
Then Git would check out another one (let's call it G) for you
to test and you record the result from two tests.
$ git bisect state good good2
As you continue, Git will find the transition between good to
bad (or it may find the transition between good2 to bad2
earlier) and would tell you things like "commit F is the first
bad commit" or "commit K is the first bad2 commit".
If that is the kind of "out-of-box" behaviour for finding state
transitions for N-traits simultaneously, I can say that may be
interesting (note that interesting and useful are two different
things ;-).
If the cost to _prepare_ a revision to be tested is far greater
than an incremental cost to perform one more test after the
revision is already prepared to be tested, allowing a session
like that might be an overall win and it could even be a huge
win (i.e. imagine that compilation of the whole system to be
tested takes very long, but once the binary to be tested is
built, the time it takes to run each individual test is
negligible---if you have ten tests in your test suite, even if
you start out to find breakage in your test #1 like the above
example, it may be more efficient if you test all ten tests, not
just test #1, once you built the system to run test #1 for the
purpose of bisecting to find the breakage of that particular
test).
But I am not sure that is the kind of problem you are trying to
solve in the first place, so...
--
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