Re: Is there interest in a n-sect tool?

Mike Hommey <mh@glandium.org> writes:

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

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