[PATCH 1 of 1] bisect: print current state of the bisection

[Yann E. MORIN]

Matt, All,

On Friday 16 September 2011 01:52:23 Matt Mackall wrote:
> On Fri, 2011-09-16 at 01:28 +0200, Yann E. MORIN wrote:
> > - pruned:
> >     all changesets that we know already participated in the bisection
> >     so far, basically, all good, bad and skipped changsets; so the set
> >     is:
> >       'bisected(good) | bisected(bad) | bisected(skip)'
> 
> This one's actually trickier.
> 
> Depending on which edge direction we've inferred,

It never occured to me that a regression could be the other way around.
But it makes sense, I agree. A direct bisection (bad<good) is to find the
cause of a regression; a reverse bisection (good<bad) is to find where a
bug disapeared. And after all, good/bad are only meaningfull for us mere
humans, and could be use either way... ;-)

> we might want to either have:
> 
> bisected(skip) and ancestors(bisected(good)) and descendants(bisected(bad))
> 
> or
> 
> bisected(skip) and ancestors(bisected(bad)) and descendants(bisected(good))

OK, you want only skipped csets that are still in the bisection range (eg.
skipped csets that are out-side the bisection scope get removed).

OK, got it.

> > - untested:
> >     all changsets that are not yet tested, and that are potential
> >     candidates for later tests; basically, it means that:
> >       - all changesets already tested are excluded
> >       - all descendant of good changesets that are ancestors of
> >         bad changesets, are included
> >     so the set looks like:
> >       'bisected(good)::bisected(bad) & ! bisected(pruned)'
> 
> s/pruned/skip/

good::bad will also return the good and bad csets, but those are not
untested: they are good (or bad). 'untested' is for remaining csets,
which we do not know whether they are good/bad?

So we should also exclude good and bad sets from the result, no?

> This also has the directionality issue.

OK.

> > - ignored:
> >     all changesets that can't participate in the bisection because
> >     of DAG topology. For example, a branch merged between the good
> >     set and the bad set, but whose branch point is before the good
> >     set, will not participate in the bisection, although the issue
> >     may originate from that branch [*]; what this means is:
> >       - all changesets already tested are excluded
> >       - all ancestors of bad changesets that are not ancestors of
> >         good changesets, are included
> >     so the set looks like:
> >       '( ::bisected(bad) - ::bisected(good) ) & ! bisected(pruned)'
> 
> Note that we can simply define any of these sets in terms of the other
> two:
> 
> ignored = !pruned and !untested

With such a definition, 'ignored' will return *all* csets of the repo,
except the pruned or untested ones. 'ignored' conveys a stronger meaning,
that is "csets that can't participate to the bisection, but might have
an impact on the outcome"; such as you perfectly explained with a merge
in the middle of good::bad

But if am wrong on all the above, just correct me (once more!) ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'