On Mon, Jan 18, 2016 at 07:54:21PM -0800, Junio C Hamano wrote: > Mike Hommey <mh@xxxxxxxxxxxx> writes: > > > On Mon, Jan 18, 2016 at 12:43:35AM -0800, Junio C Hamano wrote: > > ... > >> 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.... > >> ... 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. > > I am not sure what you meant by "Yes it is"; is the above (i.e. in a > history whose one part is painted continuously in black, one part > continuously in gray and the remainder in white where white and > black never touch, find the transition between black and gray and > the transition between gray and white) the kind of search you are > talking about? Judging from the remainder of your message, I had an > impression that you are solving a different problem where you want > to find transitions for N distinct traits (i.e. 2^N combinations, > not N distinct colors like black-gray-white). No, I'm really after N distinct colors, where I don't know N in advance. > > > That being said, while I can do these things locally with my own > > scripts, as a user, I would have found it useful if git bisect (and > > especially git bisect run) would support this out of the box. The > > question remains whether it would be useful to more people than > > just me. > > 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 Git then gives you commit G, between A and M, which you test, and it's gray. So the state map, as of now is: A - black G - gray M - gray Z - white As of now, Git is still looking for the first gray, so it gives you commit D, between A and G, etc. until you find the first gray. Once we're done finding the first gray, Git now wants you to find the first black, so goes back to bisecting between M and Z. Once all transitions are found, it outputs something like: <sha1> is the first gray commit $(git diff-tree --pretty <sha1>) <sha1_2> is the first white commit $(git diff-tree --pretty <sha1_2>) At any point, there could be additional intermediate states that we find, in which case Git would bisect them. How does that sound? 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