Re: Is there interest in a n-sect tool?

From: Mike Hommey <mh@glandium.org>
Date: Jan 20, 2016, 22:34 UTC
Message-ID: <20160120223429.GA28006@glandium.org>
In-Reply-To: <xmqqd1sv52l9.fsf@gitster.mtv.corp.google.com>

On Wed, Jan 20, 2016 at 02:05:22PM -0800, Junio C Hamano wrote:

Show 35 quoted lines

> Mike Hommey <mh@glandium.org> 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