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

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:

quoted

Mike Hommey [off-list ref] writes:

quoted

- 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