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@xxxxxxxxxxxx> 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 -- 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