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

[Matt Mackall]

On Fri, 2011-09-16 at 01:28 +0200, Yann E. MORIN wrote:
> All,
> 
> On Thursday 15 September 2011 18:56:05 Yann E. MORIN wrote:
> > # HG changeset patch
> > # User "Yann E. MORIN" <yann.morin.1998 at anciens.enib.fr>
> > # Date 1316105758 -7200
> > # Node ID 1538635da29a21230eff455150c1a2b166f2375a
> > # Parent  edf7ae547b0e475936831fb8459c850d13b2d310
> > bisect: print current state of the bisection
> 
> Forget about this. We've discussed this with mpm on IRC, and here's the
> summary of the discussion (at least what I have understood):
> 
> Enhance revset's bisect() keyword to accept three new definitions:
> 
> - 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, 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))

> - 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/

This also has the directionality issue.

> - 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

> [*] if so, then bisect will find the merged changeset as being the
>     culprit, and suggest to extend the range
> 
> Then simply use the log command to print the corresponding changesets.
> This has the nice advantage of profitting from all of the log features,
> such as graphlog (if enabled), and can also be combined with other
> revset keywords to refine the sets.
> 
> For example, if we know that the issue is in a specific file, we could
> use a set like:
>     'bisected(untested) & file(file/with/issue)'
> 
> If we know the issue was added the past two weeks, and has been present
> for the last 5 days, the set could be:
>     'bisected(untested) & date(-14 to -5)'
> 
> And so on...
> 
> Many thanks to mpm for taking the time to get me on the correct route! :-)
> 
> So, I'll get back to the drawing board, and soon after to the keyboard.
> But probably that will wait tomorrow GMT+2...
> 
> Regards,
> Yann E. MORIN.
> 


-- 
Mathematics is the supreme nostalgia of our time.