It’s also smithing that’s unleashed the ability of agents to explore and reason about code faster than waiting for some sort of “lsp-like” standard we probably would’ve had to build instead over time.
Ripgrep 15.0
51–60 of 119 posts
Re: Ripgrep 15.0
#52Earlier quoted context omitted.
Can you provide a concrete example where that's faster? ripgrep should generally already be approximating `git ls-files` by respecting gitignore. Also, `-uu` tells ripgrep to not respect gitignore and to search hidden files. But ripgrep will still skip binary files. You need `-uuu` to also ignore binary files. I tried playing with your `rgg` function. First problem occurred when I tried it on a checkout the Linux ker…
A checkout of my repository [0] with many pdf and audio files (20GB) is slow with -u. These data files are normally ignored because 1) they are in .gitignore and 2) they are binary. The repository contains CI files in .woodpecker. These are scripts that I'd normally expect to be searching in. Until a week ago I used -uu to do so, but that made rg take over 4 seconds for a search. Using -. brings the search time down…
Yes, now it makes sense. And yes, `-./--hidden` makes it moot. Thanks for following up!
Re: Ripgrep 15.0
#53Earlier quoted context omitted.
Maybe I’m missing something, but doesn’t ripgrep ignore untracked files in git by default already?
The point is to search hidden files that are tracked by git. An example is CI scripts which are stored in places like .woodpecker, .forgejo, .gitlab-ci-yml.
$ printf '!.woodpecker\n!.forgejo\n!.gitlab-ci-yml\n' > .rgignore
Or whatever you need to whitelist specific hidden directories/files.For example, ripgrep has `!/.github/` in its `.ignore` file at the root of the repository[1].
By adding the `!`, these files get whitelisted even though they are hidden. Then `rg` with no extra arguments will search them automatically while still ignoring other hidden files/directories.
[1]: https://github.com/BurntSushi/ripgrep/blob/38d630261aded3a8e...
Re: Ripgrep 15.0
#54I would prefer a solution that works from outside git repos, so no piping `git ls-files` into rg.
Re: Ripgrep 15.0
#55What is the right way to make ripgrep behave closer to `git grep`? Plain `rg` ignores files inside hidden folders like `.github`, `rg --hidden` will search `.github` but also search inside `.git`. I currently have this alias that I don't remember where I found: `rg --hidden --glob '!*/.git/*'`. Is there a better way? I would prefer a solution that works from outside git repos, so no piping `git ls-files` into rg.
That is, you can whitelist specific hidden files/directories.
There is no way to tell ripgrep to "search precisely the set of tracked files in git." ripgrep doesn't read git repository state. It just looks at gitignore files and automatically ignores all hidden and binary files. So it make it work more like git, you might consider whitelisting the hidden files you want to search. To make it work exactly like git, you need to do the `git ls-files -z | xargs -0 rg ...` dance.
Re: Ripgrep 15.0
#56Ripgrep has saved me so, so much time over the years. It's become an invaluable tool, something I install the moment I start up a new system. It's essential for navigating older codebases. My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now. Always glad to see it kee…
> My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now. If you have an example, I can try to explain for that specific case. But `-F/--fixed-strings` will 100% turn off any regex features in the pattern and instead will be treated as a simple literal. Where you might…
Totally love your work! We've been sponsoring for awhile even though it isn't much. Thank you for all you do!
Re: Ripgrep 15.0
#57This week I wrote a small bash function that run ripgrep only on the files that are tracked by git: rgg() { readarray -d '' -t FILES It speeds up a lot on directories with many binary files and committed dot files. To search the dot files, -uu is needed, but that also tells ripgrep to search the binary files. On repositories with hundreds of files, the git ls-files overhead a bit large.
Re: Ripgrep 15.0
#58Earlier quoted context omitted.
In my case, I am still using ag because rg doesn't seem to be better enough to switch. What's the big deal with rg vs ag? I had a similar thing with bash vs zsh before I learned about oh-my-zsh. Nushell also seems attractive these days... the good stuff from PowerShell in a POSIX-like shell.
ripgrep is a lot faster (which you might only notice on larger haystacks), has many fewer bugs and is maintained.
Re: Ripgrep 15.0
#59Earlier quoted context omitted.
> My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now. If you have an example, I can try to explain for that specific case. But `-F/--fixed-strings` will 100% turn off any regex features in the pattern and instead will be treated as a simple literal. Where you might…
Totally off-topic: what are the selling points of `jiff` vs chrono, time, std::time, etc.? Totally love your work! We've been sponsoring for awhile even though it isn't much. Thank you for all you do!
I'd be happy to answer more specific questions.
Short opinionated summary is: nicer API, fewer footguns, more features, better support for calendar durations, integrated tzdb support and lots more to be honest.
Note that `std::time` just gives you a platform independent but bare bones access to monotonic and system clocks. Some kind of datetime library is needed if you want to do anything with Unix timestamps beyond treat them as an integer.