On Wed, Jan 20, 2016 at 02:05:22PM -0800, Junio C Hamano wrote: > 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. Well, that's exactly the use case I had. A simplified version of it is: Find all the git-cinnabar revisions that affected the git sha1 commits corresponding to mercurial changesets in a given repository. There are multiple changes in git-cinnabar that affected the sha1 of git commits because of changes in e.g. author munging, timezone munging, etc. But without looking at the git-cinnabar `git log` extensively, I don't remember how many such changes there were and how they affect some given repositories. So, for example, with git-cinnabar commit A, mercurial changeset H would become git commit G, and with git-cinnabar commit B, mercurial changeset H would become git commit G'. With git-cinnabar commit A and B, mercurial changeset H2 would become git commit G2, but in git-cinnabar commit C, it would become git commit G2'. I'm looking for B and C, and all the others that could exist. > If that assmption holds, what you wrote would be a usable interface > and I suspect an implementable one. Considering I'm going to need this a couple more times, I'm likely to give it a spin. The main question that remains is how to make that work with `git bisect run`. I'm thinking something like this: $ git bisect state-number black 0 $ git bisect state-number white 1 $ git bisect state-number gray 2 The numbers would be assigned when the state is used for the first time. And the `bisect run` script could just do: exit $(git bisect state-number $state) `state-number` kind of sucks as a name, though. 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