[PATCH 0 of 2] fast manifest based grep

Steve Borho steve at borho.org
Mon May 17 14:33:49 CDT 2010


On Mon, May 17, 2010 at 2:21 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2010-05-17 at 14:06 -0500, Steve Borho wrote:
>> On Sun, May 16, 2010 at 2:58 PM, Matt Mackall <mpm at selenic.com> wrote:
>> > 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.
>>
>> My plan is to remove, from my patch, the checks for the annotate
>> options and allow the manifest scan method to be used for all cases,
>> except when --all and/or --rev are specified.
>
> Ok, so are these two different?
>
> hg grep -r 1.0 pat foo
> hg grep -c 1.0 pat foo
>
> I think your -c is redundant once we have a separate switch for revision
> numbers.

They could have different behavior.  'grep -r N' could be the same as
'grep -r N:N' or it could be equivalent to 'grep -c N'.  'grep -r N:N'
is not especially useful, but at least it's behavior would be
consistent with what you get with 'grep -r N:M'.

>> The manifest scan algorithm will call into commands.manifest() on
>> demand; caching the result for the current file [1].
>>
>> We still need a flag to enable revision numbers in the output.  'n',
>> 'l', 'i', 'R', 'c' are already taken.  Perhaps: '-N' '--rev-number'
>>
>> Lastly; I don't think annotation will work at all for the working copy
>> (what rev do you show for working changes?).  Should I abort if the
>> user asks for annotation for repo[None], or fallback to repo['.']?  In
>> other words:
>
> Best would be to teach annotate about working copies. But we can try to
> tackle that later.

I guess the interim solution is to bail if the user asks for annotated
working changes, so we'll be enabling this feature in the future.

--
Steve Borho


More information about the Mercurial-devel mailing list