the ripgrep codebase is ultimate “pour a drink, settle into your coziest chair, and read some high quality software” codebase. Just click around through it and marvel.
Great tool, and incredibly easy to use. Started with it on Linux, and now use on 'doze too.
Probably the singular reason why I finally use regex as the first search option, rather than turning to it after bruting thru a search with standard wildcards.
rg is a first for me in that it's a CLI tool that an LLM taught me about -- it's a go-to tool for Claude and codex, and since I got most of my bash skills pre-dotcom-one-boom I'm historically just a grep user.
Anyway I'm trying to retrain the fingers these days, rg is super cool.
the one thing i'd love to see added is an "extension" flag, equivalent to -g but which treats the provided arg as an extension (so `rg -e c,h` instead of `rg -g '*.{c,h}'`). 99% of the time I use glob patterns it's to match on extension.
ripgrep is one of the main reasons I got interested in rust. it worked so well, it piqued my interest that it was written in rust. many years later, very glad about that. been using `rg` daily since then as well!
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.
Ripgrep 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.
rg is a tool that feels like magic. when in reality, like most things that feel like magic, it’s a result of exceptionally good engineering and dedication to improvement, and actually takes advantage of the incredible hardware we all use daily.
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.
What 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.
I discovered and started using the silver searcher (ag) before ripgrep existed. I don't feel a strong need to switch for marginally faster search but with different command-line switches. Am I missing some killer feature here?
Every time I set up a new machine--work, personal, whatever--the first thing I do is set up my rust toolchain and the second is 'cargo install ripgrep'. I really enjoyed your talk at the Boston Rust meetup a few years back on finite state transducers. Thanks for these (among many more) contributions you've made both to software and my education as a programmer.
> new major version release that mostly has bug fixes, some minor performance improvements and minor new features.
It's sad that "bug fixes and performance improvements" has become a running joke as the explanation for software gavage, and this is even worse. "Fewer bugs and faster" is at least something most people want; "fewer bugs, faster, and random changes you didn't ask fork" is a lot less desirable.
31 comments
[ 0.28 ms ] story [ 57.0 ms ] threadhttps://burntsushi.net/ripgrep/
Probably the singular reason why I finally use regex as the first search option, rather than turning to it after bruting thru a search with standard wildcards.
Anyway I'm trying to retrain the fingers these days, rg is super cool.
On repositories with hundreds of files, the git ls-files overhead a bit large.
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 keep updating!
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.
I would prefer a solution that works from outside git repos, so no piping `git ls-files` into rg.
So glad to see this!
I’m happy reading releases notes more thoroughly to keep myself aware of new features.
Nice to see some better integration with jj!
It's sad that "bug fixes and performance improvements" has become a running joke as the explanation for software gavage, and this is even worse. "Fewer bugs and faster" is at least something most people want; "fewer bugs, faster, and random changes you didn't ask fork" is a lot less desirable.
https://youtu.be/OmVHkL0IWk4