A grep though history would be a very useful functionality, There have been
many times I'd have used it. Using sqlite3 glob or like for the pattern
match would be more than adequate. If you need a regex just use the glob to
select for the lowest common denominator and then pipe though egrep with
the more complex regex to filter for exactly what you want.
On Sat, Nov 24, 2012 at 7:35 AM, j. v. d. hoff <veedeeh...@googlemail.com>wrote:
> On Sat, 24 Nov 2012 15:21:54 +0100, Richard Hipp <d...@sqlite.org> wrote:
>
> On Sat, Nov 24, 2012 at 9:12 AM, j. v. d. hoff <veedeeh...@googlemail.com
>> >**wrote:
>>
>> On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp <d...@sqlite.org> wrote:
>>>
>>> On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell <
>>> vi...@viric.name
>>>
>>>> >wrote:
>>>>
>>>> On Sat, Nov 24, 2012 at 08:18:55AM -0500, Richard Hipp wrote:
>>>>
>>>>> > On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff <
>>>>> veedeeh...@googlemail.com>****wrote:
>>>>>
>>>>> >
>>>>> > > question: is there a straightforward (or sqlite-based) way to
>>>>> `grep'
>>>>> > > through a specified file recursively backward in time through all
>>>>> revisions
>>>>> > > (or until first hit of the search pattern)?
>>>>> > >
>>>>> > > j.
>>>>> > >
>>>>> > > ps: yes, I would know now (after having learned how to use `fossil
>>>>> > > artifact' correctly...) how to write a shell script doing that. but
>>>>> that
>>>>> > > would mean to dump the full content of each revision and pipe it
>>>>> through
>>>>> > > the grep which will become slow if there are too many revisions. so
>>>>> the
>>>>> > > question is whether the functionality is already builtin (possibly
>>>>> grepping
>>>>> > > through the deltas instead).
>>>>> > >
>>>>> >
>>>>> > This functionality is not built-in. Nobody has ever thought of it
>>>>> before
>>>>> > in 6 years of use, apparently, or at least has not mentioned it to
>>>>> me.
>>>>>
>>>>> I use this from time to time. My procedure goes through deconstructing
>>>>> the
>>>>> database, grepping recursive, and resolving back the hashes with fossil
>>>>> ui.
>>>>>
>>>>>
>>>>> So what should the output look like? Suppose we implement a command:
>>>>
>>>> fossil grep REGEXP FILENAMEGLOB
>>>>
>>>> Which searches all historical versions of files that match FILENAMEGLOB
>>>> for
>>>> patterns that match REGEXP. Suppose for concreteness that the regular
>>>> expression is "xyzzy" and the file is "ex1.txt". If there are 1000
>>>> different revisions of ex1.txt, does it search them all looking for
>>>> "xyzzy"
>>>> and show each hit? Or did it stop going backwards in time at the first
>>>> hit
>>>> it find?
>>>>
>>>>
>>> should stop at first hit by default but allow going through complete
>>> history optionally.
>>> I feel the `hg' people did it essentially right regarding this question:
>>>
>>> 8<----------------------------****---------------------------
>>>
>>> hg grep [OPTION]... PATTERN [FILE]...
>>>
>>> search for a pattern in specified files and revisions
>>>
>>> Search revisions of files for a regular expression.
>>>
>>> This command behaves differently than Unix grep. It only accepts
>>> Python/Perl regexps. It searches repository history, not the working
>>> directory. It always prints the revision number in which a match
>>> appears.
>>>
>>> By default, grep only prints output for the first revision of a file
>>> in
>>> which it finds a match. To get it to print every revision that
>>> contains a
>>> change in match status ("-" for a match that becomes a non-match, or
>>> "+"
>>> for a non-match that becomes a match), use the --all flag.
>>>
>>> Returns 0 if a match is found, 1 otherwise.
>>>
>>> options:
>>>
>>> -0 --print0 end fields with NUL
>>> --all print all revisions that match
>>> -a --text treat all files as text
>>> -f --follow follow changeset history, or file history
>>> across
>>> copies and renames
>>> -i --ignore-case ignore case when matching
>>> -l --files-with-matches print only filenames and revisions that match
>>> -n --line-number print matching line numbers
>>> -r --rev REV [+] only search files changed within revision range
>>> -u --user list the author (long with -v)
>>> -d --date list the date (short with -q)
>>> -I --include PATTERN [+] include names matching the given patterns
>>> -X --exclude PATTERN [+] exclude names matching the given patterns
>>> --mq operate on patch repository
>>>
>>> [+] marked option can be specified multiple times
>>> 8<----------------------------****---------------------------
>>>
>>>
>>> this of course is already quite elaborate and thus not a proposal to do
>>> the same...
>>>
>>> but the default behaviour (stop at first hit) is good, the flags `l', `r'
>>> important, `u', `d', `i' sensible in my view.
>>>
>>>
>> One big problem here is that the user will doubtless expect to have full
>> Perl regular expressions. That will mean another compile-time dependency.
>>
>
> no, no, heaven forbid. I didn't mean that. I have in mind more modest
> functionality.
> for me, at least, I would nearly be happy with fixed string patterns and
> glob patterns like
> "something*other" (or the regex equivalent "something.*other")
>
>
> And maybe also a run-time dependency if a shared library is used (as most
>> distribution packages managers will likely require). Suddenly, Fossil
>> becomes much less stand-alone and self-contained.
>>
>
> definitely no good. I'm a strong believer in "small and self-contained is
> beautiful".
> that is, what I find really appealing in `fossil'.
>
>
>
>> When I get around to working on this, perhaps I'll compromise and use a
>> simpler Posix Extended Regular Expression library that can be compiled in,
>> and thus avoid the extra dependencies.
>>
>
> yes, definitely preferable in my view. maybe there are even smaller and
> (for this purpose sufficient) pattern-matching
> libraries? even shell glob patterns might do (or what `lua' is using
> instead of regex at 1/10 LOC or so).
>
>
>>
>>
>>> j.
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> Regards,
>>>>> Lluís.
>>>>>
>>>>> ______________________________****_________________
>>>>> fossil-users mailing list
>>>>> fossil-users@lists.fossil-scm.****org <fossil-users@lists.fossil-**
>>>>> scm.org <fossil-users@lists.fossil-scm.org>>
>>>>> http://lists.fossil-scm.org:****8080/cgi-bin/mailman/listinfo/****
>>>>> fossil-users<http://lists.**fossil-scm.org:8080/cgi-bin/**
>>>>> mailman/listinfo/fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> --
>>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>>>
>>>
>>
>>
>>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> ______________________________**_________________
> fossil-users mailing list
> fossil-users@lists.fossil-scm.**org <fossil-users@lists.fossil-scm.org>
> http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
