[PATCH 0 of 2] fast manifest based grep

[Steve Borho]

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.

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

> 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)'.

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

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

--
Steve Borho