{"thread":{"id":"41211","subject":"Is there interest in a n-sect tool?","startedAt":"2016-01-18T07:56:53Z","lastAt":"2016-01-20T22:34:29Z","messageCount":8,"participants":["Mike Hommey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"276266","messageId":"20160118075653.GA13911@glandium.org","threadId":"41211","inReplyTo":null,"subject":"Is there interest in a n-sect tool?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-01-18T07:56:53Z","receivedAt":"2016-01-18T07:56:53Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\n[Some background]\nAs you may be aware, I'm working on git-cinnabar, which allows to clone\nmercurial repositories with git. I reached a point where I decided I\ndidn't want to do more without having a test suite that I can run in a\nfew minutes (or even better, seconds) instead of the hours that my\ncurrent testing setup takes (the multi-hour tests I run are still\nvaluable, though, but for different reasons).\n\nNow, what I'm doing is compiling a list of changes to git-cinnabar\nthat affected how several mercurial repositories are cloned, to\nidentify the interesting patterns that I've encountered in the past\nso that they appear in some form in the light test suite I want to\nrun on each commit.\n\nChecking clones of the 4 mercurial repositories I've been using for\nmost of my testing so far takes more than half an hour (because one\nof them is mozilla-central, and that's large). There are 300+ commits\nin the git-cinnabar repository, so testing them one by one would take\n150+ hours, or more than 6 days...\n\nThis is where binary search would be useful, but bisect only handles\ntwo states. So what I was really after is n-sect. Which, in fact, is\nkind of possible albeit cumbersome, with bisect. So I now have a semi\nautomatic half-broken setup that works for my use case.\n\nWhat it does, essentially looks like this:\n- I have a script that, for a given git-cinnabar commit, clones\n  those four mercurial repositories, and determines a global state\n  for the resulting repositories. (for example, the sha1sum of all\n  the sha1s of the remote refs for all repositories)\n- The script is run for the earliest commit and gives a sha1.\n- Then I bisect run with a script wrapping the other, returning 0\n  when the state is the same as the one for the earliest commit,\n  or 1 otherwise.\n- The result of that first bisection is the first state change.\n- Then I bisect run again, using the state of the result of that first\n  bisect instead of the earliest commit.\n- The result of that second bisection is the second state change.\n- And so on...\n\nI do, in fact, cache the states for each iteration of each bisect,\nso that I can do some smarter decisions than just start from the last\nbisection for the next one.\n\nI don't have that many state changes to track, but I do have different\nkind of states that I want to track down, so I will be running this\na couple more times.\n\nThe question is, is there sufficient interest in a generic n-sect tool\nfor me to justify spending the time to do it properly, vs. just doing\nthe minimalist thing I did to make it work for my use case.\n\nIf there is, what should it look like, UX-wise? An extra mode to bisect?\nA separate tool, which bisect could eventually become a special case of?\nOther thoughts?\n\nCheers,\n\nMike\n"},{"id":"276267","messageId":"xmqq1t9fe0qw.fsf@gitster.mtv.corp.google.com","threadId":"41211","inReplyTo":"20160118075653.GA13911@glandium.org","subject":"Re: Is there interest in a n-sect tool?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-18T08:43:35Z","receivedAt":"2016-01-18T08:43:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey <mh@glandium.org> writes:\n\n> - I have a script that, for a given git-cinnabar commit, clones\n>   those four mercurial repositories, and determines a global state\n>   for the resulting repositories. (for example, the sha1sum of all\n>   the sha1s of the remote refs for all repositories)\n> - The script is run for the earliest commit and gives a sha1.\n> - Then I bisect run with a script wrapping the other, returning 0\n>   when the state is the same as the one for the earliest commit,\n>   or 1 otherwise.\n> - The result of that first bisection is the first state change.\n> - Then I bisect run again, using the state of the result of that first\n>   bisect instead of the earliest commit.\n> - The result of that second bisection is the second state change.\n> - And so on...\n>\n> I do, in fact, cache the states for each iteration of each bisect,\n> so that I can do some smarter decisions than just start from the last\n> bisection for the next one.\n>\n> I don't have that many state changes to track, but I do have different\n> kind of states that I want to track down, so I will be running this\n> a couple more times.\n>\n> The question is, is there sufficient interest in a generic n-sect tool\n> for me to justify spending the time to do it properly, vs. just doing\n> the minimalist thing I did to make it work for my use case.\n\nAfter reading the above a few times, I still am not sure what you\nmean by n-sect (as opposed to bi-sect), especially given that you\nsounded as if you consider the straight \"bisect\" is about having\nonly two states, bad/good, new/old, or black/white.  \"Bi\" in the\nword \"bisect\" refers to the search going by dividing the space into\ntwo to find state transition, and does not necessarily mean there\nare two states (hence implying a single state transition between the\ntwo).  If you have three states, black/gray/white, that linearly\ntransitions states twice (i.e. one part of the history is\ncontinuously black, and at one boundary it turns gray and continues\nto be gray, until at another boundary it turns white and continues\nto be white to the other end), you would still \"bi\"-sect to find\nthese two transition points.  You start from a black A and a white\nZ, pick a midpoint M that tests to be gray and know the transition\npoint from black to gray exists somewhere between A and M, while the\nother transision point from gray to white exists somewhere between M\nand Z.  Is that the kind of search you are talking about?\n\nOr you may be talking about a search where there are multiple (as\nopposed to 1) independent bistate traits.  E.g. if you have two such\ntraits, perhaps you have four states in total: both bad (BB), the\nfirst trait is bad and the second trait is good (BG), good and bad\n(GB) and both good (GG).  You can tell which one of these four state\na given commit is in by running your test once.  You start from two\nendpoints, one commit that used to give you GG (i.e. the system\nwasn't broken for both) and the other that gives you BB (i.e. the\nsystem is broken for both).\n\nIn such a case, in order to find a transition for the first trait to\ngo from good to bad (GG goes to either BG or BB), you can do the\nstraight bisection, but after finishing the first bisection, it\nfeels wasteful to do a similar bisection to find a transition for\nthe other trait to go from good to bad (GG goes to either GB or BB),\nwithout taking advantage of what you already have learned from the\nfirst bisection session.\n\nIs that the problem you are solving?\n\nIf that is the problem you are solving, I think you actually can\nreuse what learned in the first bisection directly when you start\nyour second bisection without changing the current system.  \"git\nbisect good\" and \"git bisect bad\" takes zero or more commit object\nnames to mark that commit to be good or bad (they default to HEAD if\nyou do not give any), so when you start the second bisection run for\nthe second variable, you can tell \"git bisect good\" all the commits\nthat was good for the second trait you tested in the first bisect\nrun you did to find the breakage for the first trait, and similarly,\nyou can tell \"git bisect bad\" all the ones that you know are broken\nwith respect to the second trait.  After that, you would do the\nstraight bisection for the second trait.  If you have more than 2\ntraits that are independent and you can test at once, you would be\nwalking the graph painted in 8 colors, but the principle would be\nthe same.  The bisection run for the third trait would take\nadvantage of the knowledge you already have for many commits that\nyou have visited during the two previous bisection you did for the\nfirst two traits.\n\nI wouldn't call that n-section, though.  That's just n independent\nbisections running in parallel.\n"},{"id":"276268","messageId":"20160118085835.GA15642@glandium.org","threadId":"41211","inReplyTo":"xmqq1t9fe0qw.fsf@gitster.mtv.corp.google.com","subject":"Re: Is there interest in a n-sect tool?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-01-18T08:58:35Z","receivedAt":"2016-01-18T08:58:35Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Jan 18, 2016 at 12:43:35AM -0800, Junio C Hamano wrote:\n> Mike Hommey <mh@glandium.org> writes:\n> \n> > - I have a script that, for a given git-cinnabar commit, clones\n> >   those four mercurial repositories, and determines a global state\n> >   for the resulting repositories. (for example, the sha1sum of all\n> >   the sha1s of the remote refs for all repositories)\n> > - The script is run for the earliest commit and gives a sha1.\n> > - Then I bisect run with a script wrapping the other, returning 0\n> >   when the state is the same as the one for the earliest commit,\n> >   or 1 otherwise.\n> > - The result of that first bisection is the first state change.\n> > - Then I bisect run again, using the state of the result of that first\n> >   bisect instead of the earliest commit.\n> > - The result of that second bisection is the second state change.\n> > - And so on...\n> >\n> > I do, in fact, cache the states for each iteration of each bisect,\n> > so that I can do some smarter decisions than just start from the last\n> > bisection for the next one.\n> >\n> > I don't have that many state changes to track, but I do have different\n> > kind of states that I want to track down, so I will be running this\n> > a couple more times.\n> >\n> > The question is, is there sufficient interest in a generic n-sect tool\n> > for me to justify spending the time to do it properly, vs. just doing\n> > the minimalist thing I did to make it work for my use case.\n> \n> After reading the above a few times, I still am not sure what you\n> mean by n-sect (as opposed to bi-sect), especially given that you\n> sounded as if you consider the straight \"bisect\" is about having\n> only two states, bad/good, new/old, or black/white.  \"Bi\" in the\n> word \"bisect\" refers to the search going by dividing the space into\n> two to find state transition, and does not necessarily mean there\n> are two states (hence implying a single state transition between the\n> two).  If you have three states, black/gray/white, that linearly\n> transitions states twice (i.e. one part of the history is\n> continuously black, and at one boundary it turns gray and continues\n> to be gray, until at another boundary it turns white and continues\n> to be white to the other end), you would still \"bi\"-sect to find\n> these two transition points.  You start from a black A and a white\n> Z, pick a midpoint M that tests to be gray and know the transition\n> point from black to gray exists somewhere between A and M, while the\n> other transision point from gray to white exists somewhere between M\n> and Z.  Is that the kind of search you are talking about?\n\nYes, it is. Somehow, I was thinking of the result once you're done\nbisecting, not the process itself of cutting history in two parts.\n\nAnyways, \n\n> (...)\n> If that is the problem you are solving, I think you actually can\n> reuse what learned in the first bisection directly when you start\n> your second bisection without changing the current system.  \"git\n> bisect good\" and \"git bisect bad\" takes zero or more commit object\n> names to mark that commit to be good or bad (they default to HEAD if\n> you do not give any), so when you start the second bisection run for\n> the second variable, you can tell \"git bisect good\" all the commits\n> that was good for the second trait you tested in the first bisect\n> run you did to find the breakage for the first trait, and similarly,\n> you can tell \"git bisect bad\" all the ones that you know are broken\n> with respect to the second trait.  After that, you would do the\n> straight bisection for the second trait.  If you have more than 2\n> traits that are independent and you can test at once, you would be\n> walking the graph painted in 8 colors, but the principle would be\n> the same.  The bisection run for the third trait would take\n> advantage of the knowledge you already have for many commits that\n> you have visited during the two previous bisection you did for the\n> first two traits.\n\nSeems like, while you seemed to associate this paragraph with the\nother interpretation, this would work in both cases. This might, in\nfact, be less cumbersome than what I'm currently doing... I'll test it\nfor my next run, since I do need one :)\n\nThat being said, while I can do these things locally with my own\nscripts, as a user, I would have found it useful if git bisect (and\nespecially git bisect run) would support this out of the box. The\nquestion remains whether it would be useful to more people than\njust me.\n\nCheers,\n\nMike\n"},{"id":"276269","messageId":"20160118090122.GB15642@glandium.org","threadId":"41211","inReplyTo":"20160118085835.GA15642@glandium.org","subject":"Re: Is there interest in a n-sect tool?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-01-18T09:01:22Z","receivedAt":"2016-01-18T09:01:22Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Jan 18, 2016 at 05:58:35PM +0900, Mike Hommey wrote:\n> On Mon, Jan 18, 2016 at 12:43:35AM -0800, Junio C Hamano wrote:\n> > Mike Hommey <mh@glandium.org> writes:\n> > \n> > > - I have a script that, for a given git-cinnabar commit, clones\n> > >   those four mercurial repositories, and determines a global state\n> > >   for the resulting repositories. (for example, the sha1sum of all\n> > >   the sha1s of the remote refs for all repositories)\n> > > - The script is run for the earliest commit and gives a sha1.\n> > > - Then I bisect run with a script wrapping the other, returning 0\n> > >   when the state is the same as the one for the earliest commit,\n> > >   or 1 otherwise.\n> > > - The result of that first bisection is the first state change.\n> > > - Then I bisect run again, using the state of the result of that first\n> > >   bisect instead of the earliest commit.\n> > > - The result of that second bisection is the second state change.\n> > > - And so on...\n> > >\n> > > I do, in fact, cache the states for each iteration of each bisect,\n> > > so that I can do some smarter decisions than just start from the last\n> > > bisection for the next one.\n> > >\n> > > I don't have that many state changes to track, but I do have different\n> > > kind of states that I want to track down, so I will be running this\n> > > a couple more times.\n> > >\n> > > The question is, is there sufficient interest in a generic n-sect tool\n> > > for me to justify spending the time to do it properly, vs. just doing\n> > > the minimalist thing I did to make it work for my use case.\n> > \n> > After reading the above a few times, I still am not sure what you\n> > mean by n-sect (as opposed to bi-sect), especially given that you\n> > sounded as if you consider the straight \"bisect\" is about having\n> > only two states, bad/good, new/old, or black/white.  \"Bi\" in the\n> > word \"bisect\" refers to the search going by dividing the space into\n> > two to find state transition, and does not necessarily mean there\n> > are two states (hence implying a single state transition between the\n> > two).  If you have three states, black/gray/white, that linearly\n> > transitions states twice (i.e. one part of the history is\n> > continuously black, and at one boundary it turns gray and continues\n> > to be gray, until at another boundary it turns white and continues\n> > to be white to the other end), you would still \"bi\"-sect to find\n> > these two transition points.  You start from a black A and a white\n> > Z, pick a midpoint M that tests to be gray and know the transition\n> > point from black to gray exists somewhere between A and M, while the\n> > other transision point from gray to white exists somewhere between M\n> > and Z.  Is that the kind of search you are talking about?\n> \n> Yes, it is. Somehow, I was thinking of the result once you're done\n> bisecting, not the process itself of cutting history in two parts.\n\nLet me add that in my use case, I don't know how many states there are\nwhen I start. I only know there are at least two.\n\nMike\n"},{"id":"276331","messageId":"xmqqziw2b4wi.fsf@gitster.mtv.corp.google.com","threadId":"41211","inReplyTo":"20160118085835.GA15642@glandium.org","subject":"Re: Is there interest in a n-sect tool?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-19T03:54:21Z","receivedAt":"2016-01-19T03:54:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey <mh@glandium.org> writes:\n\n> On Mon, Jan 18, 2016 at 12:43:35AM -0800, Junio C Hamano wrote:\n> ...\n>> two).  If you have three states, black/gray/white, that linearly\n>> transitions states twice (i.e. one part of the history is\n>> continuously black, and at one boundary it turns gray and continues\n>> to be gray, until at another boundary it turns white and continues\n>> to be white to the other end), you would still \"bi\"-sect to find\n>> these two transition points....\n>> ...  Is that the kind of search you are talking about?\n>\n> Yes, it is. Somehow, I was thinking of the result once you're done\n> bisecting, not the process itself of cutting history in two parts.\n\nI am not sure what you meant by \"Yes it is\"; is the above (i.e. in a\nhistory whose one part is painted continuously in black, one part\ncontinuously in gray and the remainder in white where white and\nblack never touch, find the transition between black and gray and\nthe transition between gray and white) the kind of search you are\ntalking about?  Judging from the remainder of your message, I had an\nimpression that you are solving a different problem where you want\nto find transitions for N distinct traits (i.e. 2^N combinations,\nnot N distinct colors like black-gray-white).\n\n> That being said, while I can do these things locally with my own\n> scripts, as a user, I would have found it useful if git bisect (and\n> especially git bisect run) would support this out of the box. The\n> question remains whether it would be useful to more people than\n> just me.\n\nHmm, sorry.  For the two-trait example I gave (that can be extended\nto N-trait), I can sort of see how the UI might look and I can say\nit might be useful [*1*], but not with this, and especially that you\ndo not necessarily know all the traits whose transition points you\nmight be interested in a-priori--all of that makes the problem\ndefinition fuzzy to me, and I cannot imagine what kind of user\ninteraction you would be envisioning to solve what kind of problem,\nso I cannot even say it is a good idea or a bad idea.\n\n\n[Footnote]\n\n*1* I suppose a possible UI for the N-trait bisection might go like\n    this.  You start from just a single trait (good for your test #1\n    passing, bad for your test #1 failing).  You start with:\n\n    $ git bisect start\n    $ git bisect good A\n    $ git bisect bad Z\n\n    and Git would give you a commit (let's call it M) to test.  You\n    test and find that test #1 passes, but at the same time you find\n    that test #2 does not pass.  You do not know if test #2 passes\n    or fails at A nor Z.  At this point, you would decide to call\n    \"test #2 passes\" as good2, \"test #2 fails\" as bad2.  We now have\n    two independent traits (good/bad and good2/bad2), and mark M as\n    good and bad2:\n\n    $ git bisect add-trait new/old/unknown=good2/bad2/unknown2\n    $ git bisect state good bad2\n\n    Then Git would check out another one (let's call it G) for you\n    to test and you record the result from two tests.\n\n    $ git bisect state good good2\n\n    As you continue, Git will find the transition between good to\n    bad (or it may find the transition between good2 to bad2\n    earlier) and would tell you things like \"commit F is the first\n    bad commit\" or \"commit K is the first bad2 commit\".\n\n    If that is the kind of \"out-of-box\" behaviour for finding state\n    transitions for N-traits simultaneously, I can say that may be\n    interesting (note that interesting and useful are two different\n    things ;-).\n\n    If the cost to _prepare_ a revision to be tested is far greater\n    than an incremental cost to perform one more test after the\n    revision is already prepared to be tested, allowing a session\n    like that might be an overall win and it could even be a huge\n    win (i.e. imagine that compilation of the whole system to be\n    tested takes very long, but once the binary to be tested is\n    built, the time it takes to run each individual test is\n    negligible---if you have ten tests in your test suite, even if\n    you start out to find breakage in your test #1 like the above\n    example, it may be more efficient if you test all ten tests, not\n    just test #1, once you built the system to run test #1 for the\n    purpose of bisecting to find the breakage of that particular\n    test).\n\n    But I am not sure that is the kind of problem you are trying to\n    solve in the first place, so...\n"},{"id":"276333","messageId":"20160119045719.GA11680@glandium.org","threadId":"41211","inReplyTo":"xmqqziw2b4wi.fsf@gitster.mtv.corp.google.com","subject":"Re: Is there interest in a n-sect tool?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-01-19T04:57:19Z","receivedAt":"2016-01-19T04:57:19Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Jan 18, 2016 at 07:54:21PM -0800, Junio C Hamano wrote:\n> Mike Hommey <mh@glandium.org> writes:\n> \n> > On Mon, Jan 18, 2016 at 12:43:35AM -0800, Junio C Hamano wrote:\n> > ...\n> >> two).  If you have three states, black/gray/white, that linearly\n> >> transitions states twice (i.e. one part of the history is\n> >> continuously black, and at one boundary it turns gray and continues\n> >> to be gray, until at another boundary it turns white and continues\n> >> to be white to the other end), you would still \"bi\"-sect to find\n> >> these two transition points....\n> >> ...  Is that the kind of search you are talking about?\n> >\n> > Yes, it is. Somehow, I was thinking of the result once you're done\n> > bisecting, not the process itself of cutting history in two parts.\n> \n> I am not sure what you meant by \"Yes it is\"; is the above (i.e. in a\n> history whose one part is painted continuously in black, one part\n> continuously in gray and the remainder in white where white and\n> black never touch, find the transition between black and gray and\n> the transition between gray and white) the kind of search you are\n> talking about?  Judging from the remainder of your message, I had an\n> impression that you are solving a different problem where you want\n> to find transitions for N distinct traits (i.e. 2^N combinations,\n> not N distinct colors like black-gray-white).\n\nNo, I'm really after N distinct colors, where I don't know N in advance.\n> \n> > That being said, while I can do these things locally with my own\n> > scripts, as a user, I would have found it useful if git bisect (and\n> > especially git bisect run) would support this out of the box. The\n> > question remains whether it would be useful to more people than\n> > just me.\n> \n> Hmm, sorry.  For the two-trait example I gave (that can be extended\n> to N-trait), I can sort of see how the UI might look and I can say\n> it might be useful [*1*], but not with this, and especially that you\n> do not necessarily know all the traits whose transition points you\n> might be interested in a-priori--all of that makes the problem\n> definition fuzzy to me, and I cannot imagine what kind of user\n> interaction you would be envisioning to solve what kind of problem,\n> so I cannot even say it is a good idea or a bad idea.\n\nHow about something like this:\n\n$ git bisect start\n$ git bisect state black A\n$ git bisect state white Z\n\nGit then gives you commit M to test, between A and Z. Now, you test M,\nand the result is that it's neither black or white, but gray, so you\nwould do:\n\n$ git bisect state gray\n\nGit then gives you commit G, between A and M, which you test, and it's\ngray. So the state map, as of now is:\n\nA - black\nG - gray\nM - gray\nZ - white\n\nAs of now, Git is still looking for the first gray, so it gives you\ncommit D, between A and G, etc. until you find the first gray.\n\nOnce we're done finding the first gray, Git now wants you to find the\nfirst black, so goes back to bisecting between M and Z.\n\nOnce all transitions are found, it outputs something like:\n<sha1> is the first gray commit\n$(git diff-tree --pretty <sha1>)\n\n<sha1_2> is the first white commit\n$(git diff-tree --pretty <sha1_2>)\n\nAt any point, there could be additional intermediate states that we\nfind, in which case Git would bisect them.\n\nHow does that sound?\n\nMike\n"},{"id":"276460","messageId":"xmqqd1sv52l9.fsf@gitster.mtv.corp.google.com","threadId":"41211","inReplyTo":"20160119045719.GA11680@glandium.org","subject":"Re: Is there interest in a n-sect tool?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-20T22:05:22Z","receivedAt":"2016-01-20T22:05:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey <mh@glandium.org> writes:\n\n> On Mon, Jan 18, 2016 at 07:54:21PM -0800, Junio C Hamano wrote:\n>\n>> Hmm, sorry.  For the two-trait example I gave (that can be extended\n>> to N-trait), I can sort of see how the UI might look and I can say\n>> it might be useful [*1*], but not with this, and especially that you\n>> do not necessarily know all the traits whose transition points you\n>> might be interested in a-priori--all of that makes the problem\n>> definition fuzzy to me, and I cannot imagine what kind of user\n>> interaction you would be envisioning to solve what kind of problem,\n>> so I cannot even say it is a good idea or a bad idea.\n>\n> How about something like this:\n>\n> $ git bisect start\n> $ git bisect state black A\n> $ git bisect state white Z\n>\n> Git then gives you commit M to test, between A and Z. Now, you test M,\n> and the result is that it's neither black or white, but gray, so you\n> would do:\n>\n> $ git bisect state gray\n\nIs it assumed throughout the bisect session that the only boundary\nblack touches is with gray (or some other color) and the only\nboundaries gray touches are either with black or with white,\ni.e. there is no path that goes from black to gray back to black and\nthen to white?  That is the parallel to the requirement a\nbog-standard bisection has (i.e. \"one side is all black, once you\ncross the boundary to white, remainder is all white\").\n\nI just cannot see a realistic use case where that assumption holds\nand still you do not know a-priori how many colors there are.\n\nIf that assmption holds, what you wrote would be a usable interface\nand I suspect an implementable one.\n"},{"id":"276463","messageId":"20160120223429.GA28006@glandium.org","threadId":"41211","inReplyTo":"xmqqd1sv52l9.fsf@gitster.mtv.corp.google.com","subject":"Re: Is there interest in a n-sect tool?","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-01-20T22:34:29Z","receivedAt":"2016-01-20T22:34:29Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Jan 20, 2016 at 02:05:22PM -0800, Junio C Hamano wrote:\n> Mike Hommey <mh@glandium.org> writes:\n> \n> > On Mon, Jan 18, 2016 at 07:54:21PM -0800, Junio C Hamano wrote:\n> >\n> >> Hmm, sorry.  For the two-trait example I gave (that can be extended\n> >> to N-trait), I can sort of see how the UI might look and I can say\n> >> it might be useful [*1*], but not with this, and especially that you\n> >> do not necessarily know all the traits whose transition points you\n> >> might be interested in a-priori--all of that makes the problem\n> >> definition fuzzy to me, and I cannot imagine what kind of user\n> >> interaction you would be envisioning to solve what kind of problem,\n> >> so I cannot even say it is a good idea or a bad idea.\n> >\n> > How about something like this:\n> >\n> > $ git bisect start\n> > $ git bisect state black A\n> > $ git bisect state white Z\n> >\n> > Git then gives you commit M to test, between A and Z. Now, you test M,\n> > and the result is that it's neither black or white, but gray, so you\n> > would do:\n> >\n> > $ git bisect state gray\n> \n> Is it assumed throughout the bisect session that the only boundary\n> black touches is with gray (or some other color) and the only\n> boundaries gray touches are either with black or with white,\n> i.e. there is no path that goes from black to gray back to black and\n> then to white?  That is the parallel to the requirement a\n> bog-standard bisection has (i.e. \"one side is all black, once you\n> cross the boundary to white, remainder is all white\").\n> \n> I just cannot see a realistic use case where that assumption holds\n> and still you do not know a-priori how many colors there are.\n\nWell, that's exactly the use case I had. A simplified version of it is:\n\nFind all the git-cinnabar revisions that affected the git sha1 commits\ncorresponding to mercurial changesets in a given repository. There are\nmultiple changes in git-cinnabar that affected the sha1 of git commits\nbecause of changes in e.g. author munging, timezone munging, etc.\nBut without looking at the git-cinnabar `git log` extensively, I don't\nremember how many such changes there were and how they affect some given\nrepositories.\n\nSo, for example, with git-cinnabar commit A, mercurial changeset H\nwould become git commit G, and with git-cinnabar commit B, mercurial\nchangeset H would become git commit G'. With git-cinnabar commit A and B,\nmercurial changeset H2 would become git commit G2, but in git-cinnabar\ncommit C, it would become git commit G2'. I'm looking for B and C, and\nall the others that could exist.\n\n> If that assmption holds, what you wrote would be a usable interface\n> and I suspect an implementable one.\n\nConsidering I'm going to need this a couple more times, I'm likely to\ngive it a spin. The main question that remains is how to make that work\nwith `git bisect run`. I'm thinking something like this:\n\n$ git bisect state-number black\n0\n$ git bisect state-number white\n1\n$ git bisect state-number gray\n2\n\nThe numbers would be assigned when the state is used for the first time.\nAnd the `bisect run` script could just do:\n\nexit $(git bisect state-number $state)\n\n`state-number` kind of sucks as a name, though.\n\nMike\n"}]}