Hi, [Some background] As you may be aware, I'm working on git-cinnabar, which allows to clone mercurial repositories with git. I reached a point where I decided I didn't want to do more without having a test suite that I can run in a few minutes (or even better, seconds) instead of the hours that my current testing setup takes (the multi-hour tests I run are still valuable, though, but for different reasons). Now, what I'm doing is compiling a list of changes to git-cinnabar that affected how several mercurial repositories are cloned, to identify the interesting patterns that I've encountered in the past so that they appear in some form in the light test suite I want to run on each commit. Checking clones of the 4 mercurial repositories I've been using for most of my testing so far takes more than half an hour (because one of them is mozilla-central, and that's large). There are 300+ commits in the git-cinnabar repository, so testing them one by one would take 150+ hours, or more than 6 days... This is where binary search would be useful, but bisect only handles two states. So what I was really after is n-sect. Which, in fact, is kind of possible albeit cumbersome, with bisect. So I now have a semi automatic half-broken setup that works for my use case. What it does, essentially looks like this: - 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. If there is, what should it look like, UX-wise? An extra mode to bisect? A separate tool, which bisect could eventually become a special case of? Other thoughts? Cheers, 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