On Mon, Jan 28, 2013 at 5:37 PM, Richard Hipp wrote:
>
> I haven't yet figure out the right syntax for doing a grep of files in the
> repository. The implementation should be relatively easy once the right
> interface is designed. Suggestions are welcomed.
>
>
My 2 cents:
fossil grep [--type
On Tue, 29 Jan 2013 09:17:11 +0100, Lluís Batlle i Rossell
wrote:
>Well, at least for me, it's very important to be able to grep wiki pages and
>specially tickets too. I think 'export' won't work, right?
Right. Grep should be able to scan any item in the repo, not just
code. I just happen not to
On Tue, Jan 29, 2013 at 08:59:19AM +0100, Gilles wrote:
> On Tue, 29 Jan 2013 00:10:26 -0700, Matt Welland
> wrote:
> >Sorry, didn't paste in the second grep:
>
> Thanks for contributing this work-around. I guess it shows that
> there's a need for an easy, integrated grep to find code in the
> re
On Tue, 29 Jan 2013 00:10:26 -0700, Matt Welland
wrote:
>Sorry, didn't paste in the second grep:
Thanks for contributing this work-around. I guess it shows that
there's a need for an easy, integrated grep to find code in the
repository.
___
fossil-user
Sorry, didn't paste in the second grep:
fsl export | grep -A 10 -B 10 :1906
On Tue, Jan 29, 2013 at 12:08 AM, Matt Welland wrote:
> I haven't read all of the messages in this thread so please pardon the top
> post and possible useless or redundant info but my lazy and oh so very
> wrong metho
I haven't read all of the messages in this thread so please pardon the top
post and possible useless or redundant info but my lazy and oh so very
wrong method of grepping an entire fossil repo is to use fossil export and
some grepping. No need to put the whole expanded repo on disk.
First find the
On Mon, Jan 28, 2013 at 08:35:57PM +0100, j. v. d. hoff wrote:
> this would not prevent,
> that people run into the exponential run time problem when using the
> "naive" pattern instead the anchored one, but this could be
> explained by a FAQ entry making
> the problem practically irrelevant. or do
On Mon, 28 Jan 2013 19:46:13 +0100, Richard Hipp wrote:
I think another point is that the Lua regexp does not do anchoring (or at
least I didn't see it - did I miss something?)
see also here (from http://www.lua.org/pil/20.4.html):
Usually, pattern matching is efficient enough for Lua progra
On Mon, 28 Jan 2013 19:40:17 +0100, Joerg Sonnenberger
wrote:
On Mon, Jan 28, 2013 at 07:26:32PM +0100, j. v. d. hoff wrote:
On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger
wrote:
>On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:
>>On Mon, 28 Jan 2013 17:34:44 +0100,
On Mon, 28 Jan 2013 19:46:13 +0100, Richard Hipp wrote:
On Mon, Jan 28, 2013 at 1:40 PM, Joerg Sonnenberger
wrote:
You don't understand me. Anchoring helps, if you can use it to avoid
initial wild cards or limit the length of backtracking. It doesn't help
to avoid the exponential edge cas
On Mon, Jan 28, 2013 at 1:40 PM, Joerg Sonnenberger wrote:
>
> You don't understand me. Anchoring helps, if you can use it to avoid
> initial wild cards or limit the length of backtracking. It doesn't help
> to avoid the exponential edge cases with .*foo patterns though.
>
I think another point
On Mon, Jan 28, 2013 at 07:26:32PM +0100, j. v. d. hoff wrote:
> On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger
> wrote:
>
> >On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:
> >>On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
> >> wrote:
> >>
> >>>On Mon, Jan 28, 2
On Mon, Jan 28, 2013 at 1:30 PM, Petr P wrote:
>
> 2013/1/28 Richard Hipp
>
>>
>> I haven't yet figure out the right syntax for doing a grep of files in
>> the repository. The implementation should be relatively easy once the
>> right interface is designed. Suggestions are welcomed.
>>
>
> I t
2013/1/28 Richard Hipp
>
> I haven't yet figure out the right syntax for doing a grep of files in the
> repository. The implementation should be relatively easy once the right
> interface is designed. Suggestions are welcomed.
>
I think there are three use cases: (1) searching timeline, (2) se
On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger
wrote:
On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:
On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
wrote:
>On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
>>The regular expression matching in
>
On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:
> On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
> wrote:
>
> >On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
> >>The regular expression matching in
> >>www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also
On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
wrote:
On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
The regular expression matching in
www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and
it
supports | and it is usually as fast or faster than gre
On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
> The regular expression matching in
> www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also lightweight and it
> supports | and it is usually as fast or faster than grep in my tests
> (though there are some cases for which grep is fas
On Mon, 28 Jan 2013 10:37:19 -0500, Richard Hipp
wrote:
>test-grep is recent.
>
>And so far, test-grep does not do what you are wanting it to do. test-grep
>is just a test platform for the regexp engine.
No problem. I had no urgent need of grep, just a useful feature.
__
On Mon, 28 Jan 2013 16:29:18 +0100, Eduardo Morras
wrote:
>You can use a similar approach for your grep problem and if you are trying to
>find when you add something use fossil bisect
Thanks for the idea. I'm using Windows, but it's a useful script.
_
On Mon, Jan 28, 2013 at 10:27 AM, Gilles wrote:
> On Mon, 28 Jan 2013 07:15:13 -0500, Richard Hipp
> wrote:
> >Fossil already has
> >http://www.fossil-scm.org/fossil/artifact/c8fb75a1615f?ln=21-23 and the
> >"test-grep" command.
>
> "test-grep" doesn't show up with "fossil help *" in my 1.24. Wa
On Mon, 28 Jan 2013 15:25:19 +0100
Gilles wrote:
> On Mon, 28 Jan 2013 11:22:11 +0100, Lluís Batlle i Rossell
> wrote:
> >> Is there a way to avoid writing all those files to disk, and just
> >> output data to STDOUT and read this with grep?
> >
> >I don't know how to do that.
>
> Thanks. I'll
On Mon, 28 Jan 2013 07:15:13 -0500, Richard Hipp
wrote:
>Fossil already has
>http://www.fossil-scm.org/fossil/artifact/c8fb75a1615f?ln=21-23 and the
>"test-grep" command.
"test-grep" doesn't show up with "fossil help *" in my 1.24. Was it
added recently and not yet available in the Windows binary
On Mon, 28 Jan 2013 11:22:11 +0100, Lluís Batlle i Rossell
wrote:
>> Is there a way to avoid writing all those files to disk, and just
>> output data to STDOUT and read this with grep?
>
>I don't know how to do that.
Thanks. I'll see if there's a way to create some kind of temporary
disk in RAM.
On Mon, Jan 28, 2013 at 7:24 AM, j. van den hoff
wrote:
> On Mon, 28 Jan 2013 12:15:22 +0100, Stephan Beal
> wrote:
>
> I'm quite sure that this is _not_ a standard regexp lib, but rather lua's
> own (and somewhat different) substitute, called lua patterns, I believe.
> the lua authors used to ma
On Mon, 28 Jan 2013 12:15:22 +0100, Stephan Beal
wrote:
On Sat, Nov 24, 2012 at 3:21 PM, Richard Hipp wrote:
One big problem here is that the user will doubtless expect to have full
Perl regular expressions. That will mean another compile-time
dependency.
And maybe also a run-time depen
On Mon, Jan 28, 2013 at 6:15 AM, Stephan Beal wrote:
> On Sat, Nov 24, 2012 at 3:21 PM, Richard Hipp wrote:
>
>> One big problem here is that the user will doubtless expect to have full
>> Perl regular expressions. That will mean another compile-time dependency.
>> And maybe also a run-time dep
On Sat, Nov 24, 2012 at 3:21 PM, Richard Hipp wrote:
> One big problem here is that the user will doubtless expect to have full
> Perl regular expressions. That will mean another compile-time dependency.
> And maybe also a run-time dependency if a shared library is used (as most
> distribution p
On Mon, Jan 28, 2013 at 11:01:32AM +0100, Gilles wrote:
> On Mon, 28 Jan 2013 10:43:19 +0100, Lluís Batlle i Rossell
> wrote:
> >> What do you mean by "deconstruct"? Checking files out?
> >
> >As this question goes to me...
> >$ fossil help deconstruct
>
> Thanks. After running "deconstruct", do
On Mon, 28 Jan 2013 10:43:19 +0100, Lluís Batlle i Rossell
wrote:
>> What do you mean by "deconstruct"? Checking files out?
>
>As this question goes to me...
>$ fossil help deconstruct
Thanks. After running "deconstruct", do you just grep through all the
files, regardless of whether they contain
On Mon, Jan 28, 2013 at 10:21:03AM +0100, Gilles wrote:
> On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp
> wrote:
> >On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell
> >wrote:
> >> On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote:
> >> >
> >> > Since this thread is a bit long, I'd li
On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp
wrote:
>On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell wrote:
>> On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote:
>> >
>> > Since this thread is a bit long, I'd like to ask: At this point, what
>> > is the solution to find a piece of c
On Wed, 5 Dec 2012 08:40:14 -0500, Richard Hipp
wrote:
>(1) grep function_name *.c */*.c# Adjust GLOB expressions as appropriate
>(2) fossil up prev
>(3) goto (1)
Thank you. It works, although I also agree that grep within Fossil
would be a good feature.
_
On Wed, Dec 5, 2012 at 8:38 AM, Lluís Batlle i Rossell wrote:
> On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote:
> > On Sat, 24 Nov 2012 13:57:41 +0100, "j. v. d. hoff"
> > wrote:
> > >question: is there a straightforward (or sqlite-based) way to `grep'
> > >through a specified file recurs
On Wed, Dec 05, 2012 at 01:51:51PM +0100, Gilles wrote:
> On Sat, 24 Nov 2012 13:57:41 +0100, "j. v. d. hoff"
> 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 o
On Sat, 24 Nov 2012 13:57:41 +0100, "j. v. d. hoff"
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)?
Since this thread is a bit long, I'd like
Am Montag, 26. November 2012, 09:08:21 schrieb Andreas Kupries:
> > Fossil, like many other VCSes, compresses revisions internally, and stores
> > only some sort of deltas. I don't know how it is actually done, but
> > usually, it's some sort of patches.
>
> FYI
>
> http://www.fossil-scm.org/ind
> Fossil, like many other VCSes, compresses revisions internally, and stores
> only some sort of deltas. I don't know how it is actually done, but usually,
> it's some sort of patches.
FYI
http://www.fossil-scm.org/index.html/doc/trunk/www/delta_encoder_algorithm.wiki
http://www.fossil-scm.org/i
On 25/11/2012, at 9:24 AM, Richard Hipp wrote:
>
>
> On Sat, Nov 24, 2012 at 5:02 PM, Gilles wrote:
> On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp
> wrote:
> >One big problem here is that the user will doubtless expect to have full
> >Perl regular expressions. That will mean another compi
* Gilles [20121124 23:01]:
> On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp
> wrote:
> >One big problem here is that the user will doubtless expect to have full
> >Perl regular expressions. That will mean another compile-time dependency.
> >And maybe also a run-time dependency if a shared libr
On Sat, Nov 24, 2012 at 9:53 PM, Bernd Paysan wrote:
> Am Samstag, 24. November 2012, 20:28:16 schrieb j. v. d. hoff:
> > what you propose could easily be filter out from a full recursive search
> > backward through all revisions (and it would require such a search),
> right?
>
> Fossil, like man
On Sun, 25 Nov 2012 00:17:44 +0100, "j. v. d. hoff"
wrote:
>would intgration of the lua library
>
>http://www.lua.org/
>
>be a silly idea? it's under MIT licence, has very small footprint (quite
>probable smaller than a full fledged regex lib), and has a quite powerful
>pattern matching facili
On Sat, Nov 24, 2012 at 5:02 PM, Gilles wrote:
> On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp
> wrote:
> >One big problem here is that the user will doubtless expect to have full
> >Perl regular expressions. That will mean another compile-time dependency.
> >And maybe also a run-time depend
On Sat, 24 Nov 2012 23:42:02 +0100, James Turner
wrote:
What about just using regex(3)? It's included with BSD and quite
possibly Linux distributions, but I have no way of checking.
No idea how good the library is, but it might cut down on dependencies?
would intgration of the lua library
What about just using regex(3)? It's included with BSD and quite
possibly Linux distributions, but I have no way of checking.
No idea how good the library is, but it might cut down on dependencies?
--
James Turner
ja...@calminferno.net
___
fossil-users
Stefan Bellon wrote:
>I'd rather vote for a "list all matching revisions"
>in the --all case and the default behaviour to stop at the "most recent
>match".
I think there are three cases, the third being the earliest matching revision.
Especially if the current revision is a match. Having the d
On Sat, 24 Nov 2012 09:21:54 -0500, Richard Hipp
wrote:
>One big problem here is that the user will doubtless expect to have full
>Perl regular expressions. That will mean another compile-time dependency.
>And maybe also a run-time dependency if a shared library is used (as most
>distribution pac
On Sat, 24 Nov, Bernd Paysan wrote:
> % fossil grep xyzzy ext1.txt
> 7c88a35016..cbaff03a91:ext1.txt:here we have the *xyzzy* string
I would be in favour of this approach for a version control system with
the concept of serial, incremental revision numbers where you can
deduce from a range N..M w
Am Samstag, 24. November 2012, 20:28:16 schrieb j. v. d. hoff:
> what you propose could easily be filter out from a full recursive search
> backward through all revisions (and it would require such a search), right?
Fossil, like many other VCSes, compresses revisions internally, and stores
only s
On Sat, 24 Nov 2012 20:05:55 +0100, Bernd Paysan
wrote:
Am Samstag, 24. November 2012, 08:59:58 schrieb Richard Hipp:
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 FILENAME
Am Samstag, 24. November 2012, 08:59:58 schrieb Richard Hipp:
> 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 c
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
th
On Sat, 24 Nov 2012 15:21:54 +0100, Richard Hipp wrote:
On Sat, Nov 24, 2012 at 9:12 AM, j. v. d. hoff
wrote:
On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp wrote:
On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell
>wrote:
On Sat, Nov 24, 2012 at 08:18:55AM -0500, Richard Hip
On Sat, Nov 24, 2012 at 9:12 AM, j. v. d. hoff wrote:
> On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp wrote:
>
> On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell > >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.
On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp wrote:
On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell
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
On Sat, Nov 24, 2012 at 08:59:58AM -0500, Richard Hipp wrote:
> On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell
> 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:
> > >
>
On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell 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'
> >
On Sat, 24 Nov 2012 14:18:55 +0100, Richard Hipp wrote:
On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff
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
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
> 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 hi
On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff 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 havin
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
61 matches
Mail list logo
