[PATCH 0 of 2] fast manifest based grep

[Matt Mackall]

On Sun, 2010-05-16 at 14:48 -0500, Steve Borho wrote:
> On Sun, May 16, 2010 at 11:17 AM, Matt Mackall <mpm at selenic.com> wrote:
> > On Sat, 2010-05-15 at 23:45 -0500, Steve Borho wrote:
> >> >> 1) No longer report a revision number by default
> >> >
> >> > How do we get them back?
> >>
> >> By asking for annotation data.  Any use of 'user', 'date', 'follow',
> >> 'rev', or 'all' will fall back to the filerev search routine that
> >> outputs a revision field.
> >
> > Ok, it seems there's no way to get back to precisely the current default
> > behavior (however silly it is), is that correct?
> 
> The -r tip:null syntax gives you the exact behavior as before.

Ahh, right.

> For what it's worth, I wouldn't mind hiding the new functionality
> behind grep -c for now, leaving the default behavior as it is.   The
> only problem is there's no clear way to specify -c "working copy".

The current behavior seems a bit nonsensical, so let's explore fixing it
up a bit more.

> > Annotate uses -n to show a number.
> 
> annotate and grep are a bit at odds:
> hg ann -n == show revision
> hg grep -n == show line number
> hg ann -l == show line number
> hg grep -l == show matching files
> 
> I'm guessing this was done to keep 'hg grep' close to 'grep(1)'.

Yep.

> > If we're going to change this command's behavior, I think we're going to
> > need to rethink the whole thing: I only want to break it once. What does
> > an ideal grep command that's a superset of the current and proposed
> > functionality look like?
> >
> > Some requirements:
> >
> > - should be able to search working copy or single csets
> > - should be fast by default
> > - should be able to search all of history
> > - should be able to annotate results meaningfully in both modes
> >
> > This last is mostly about reporting revision numbers (and dates and
> > authors) in a useful way. Our choices are:
> >
> > - show last cset where file was changed (usually meaningless)
> > - show latest revision pattern appears in (redundant on single cset
> > searches)
> > - show cset where pattern introduced (slow)
> >
> > The last basically means calling annotate on each file with a match.
> > Which is slow, but it's fast when your next step would be manually
> > running annotate.
> 
> The last option is probably the only truly helpful one, or at least
> find the last revision to modify the matched line (whether or not it
> affected the pattern text).
> 
> The "--all" code path gives you this implicitly, so it's just a matter
> of adding a line-annotation lookup to the fast path.
> 
> Then there's the question of whether we keep the revision range search.

I think so.

> > (Also, your patch breaks -a.)
> 
> I think that was a bad example on my part.  grep --all has never had a
> -a short form, near as I can tell.

Actually, I think I confused myself looking at the annotate help and the
grep(1) help, where -a means treat as text.

-- 
Mathematics is the supreme nostalgia of our time.