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

[Mike Hommey <mh@glandium.org>]

On Mon, Jan 18, 2016 at 05:58:35PM +0900, Mike Hommey wrote:
> On Mon, Jan 18, 2016 at 12:43:35AM -0800, Junio C Hamano wrote:
> > Mike Hommey <mh@glandium.org> writes:
> > 
> > > - I have a script that, for a given git-cinnabar commit, clones
> > >   those four mercurial repositories, and determines a global state
> > >   for the resulting repositories. (for example, the sha1sum of all
> > >   the sha1s of the remote refs for all repositories)
> > > - The script is run for the earliest commit and gives a sha1.
> > > - Then I bisect run with a script wrapping the other, returning 0
> > >   when the state is the same as the one for the earliest commit,
> > >   or 1 otherwise.
> > > - The result of that first bisection is the first state change.
> > > - Then I bisect run again, using the state of the result of that first
> > >   bisect instead of the earliest commit.
> > > - The result of that second bisection is the second state change.
> > > - And so on...
> > >
> > > I do, in fact, cache the states for each iteration of each bisect,
> > > so that I can do some smarter decisions than just start from the last
> > > bisection for the next one.
> > >
> > > I don't have that many state changes to track, but I do have different
> > > kind of states that I want to track down, so I will be running this
> > > a couple more times.
> > >
> > > The question is, is there sufficient interest in a generic n-sect tool
> > > for me to justify spending the time to do it properly, vs. just doing
> > > the minimalist thing I did to make it work for my use case.
> > 
> > After reading the above a few times, I still am not sure what you
> > mean by n-sect (as opposed to bi-sect), especially given that you
> > sounded as if you consider the straight "bisect" is about having
> > only two states, bad/good, new/old, or black/white.  "Bi" in the
> > word "bisect" refers to the search going by dividing the space into
> > two to find state transition, and does not necessarily mean there
> > are two states (hence implying a single state transition between the
> > 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.  You start from a black A and a white
> > Z, pick a midpoint M that tests to be gray and know the transition
> > point from black to gray exists somewhere between A and M, while the
> > other transision point from gray to white exists somewhere between M
> > and Z.  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.

Let me add that in my use case, I don't know how many states there are
when I start. I only know there are at least two.

Mike