Mike Hommey <mh@xxxxxxxxxxxx> writes: > On Mon, Jan 18, 2016 at 07:54:21PM -0800, Junio C Hamano wrote: > >> 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. > > How about something like this: > > $ git bisect start > $ git bisect state black A > $ git bisect state white Z > > Git then gives you commit M to test, between A and Z. Now, you test M, > and the result is that it's neither black or white, but gray, so you > would do: > > $ git bisect state gray Is it assumed throughout the bisect session that the only boundary black touches is with gray (or some other color) and the only boundaries gray touches are either with black or with white, i.e. there is no path that goes from black to gray back to black and then to white? That is the parallel to the requirement a bog-standard bisection has (i.e. "one side is all black, once you cross the boundary to white, remainder is all white"). I just cannot see a realistic use case where that assumption holds and still you do not know a-priori how many colors there are. If that assmption holds, what you wrote would be a usable interface and I suspect an implementable one. -- 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