[PATCH 4 of 4 hyperblame] annotate: add a new experimental --skip option to skip revs

[Siddharth Agarwal]

On 5/25/17 10:14 PM, Gregory Szorc wrote:
> On Thu, May 25, 2017 at 8:24 PM, Siddharth Agarwal 
> <sid at less-broken.com <mailto:sid at less-broken.com>> wrote:
>
>     On 5/25/17 8:19 PM, Gregory Szorc wrote:
>
>         I could also imagine the inverse of a skip feature: an
>         "include" feature. You could use this to say "only annotate
>         revisions that correspond to tagged revisions" so you could
>         easily see how a file evolved from release to release.
>
>
>
>     Huh, interesting. I hadn't thought of that.
>
>
> Following that line of thought, why are we defining this in terms of a 
> "skip" list? Everything else in Mercurial that speaks in revisions 
> does so in an inclusive manner. e.g. `hg log` can be thought of as `hg 
> log -r 'all()'`. The feature we're talking about essentially turns `hg 
> annotate` from "start at <revision> and consider all() revisions that 
> are ancestors" to "start at <revision> and consider <revset> revisions 
> that are ancestors," as a skip list is essentially "all() - <skips>." 
> So we /could/ invert the design so we teach `hg annotate` which 
> revisions to "consider" or are "relevant." `hg annotate -r 123 --from 
> 'all() - desc(backout) - desc(REFACTOR)'` or something to that effect. 
> The only thing this really changes is that files defining revsets 
> would have to invert inclusion. e.g. instead of "X\nY" the file is 
> "all()\n-X\n-Y". That's mildly more annoying, but arguably more useful 
> and flexible than figuring out semantics when there is an implicit 
> all() involved.

Hmm, so thinking about this a bit more, there are actually two 
completely different use cases here.

1. Large-scale codemods, for which the most useful thing to present here 
is the nearest changeset that's an *ancestor* of a skipped cset.
2. "What changed in <e.g. tag>", for which the most useful thing to 
present is the nearest changeset that's a *descendant* of a skipped cset.

The two cases are quite different, and probably deserve different UI 
surfaces. I'm only solving case 1 for now.

Case 2 definitely doesn't involve any heuristics for linear commits, and 
probably doesn't for branchy history, though I haven't fully worked out 
the latter.