This, and also it ignores irrelevant files. It has sane defaults but you can tweak this with a .rgignore file, which is like .gitignore but for rg. By the way, it will use .gitignore files in a git directory.

That means that by default, it will take a lot less time and won't ruin your terminal when lines of some generated files (especially minified ones that are all on one line) match your search.

This is the main reason I use ripgrep.

> By the way, it will use .gitignore files in a git directory.

If I'm in a repo, I'm using `git grep`.

That makes `rg` a mostly redundant tool for me since it's optimized for searching source code. I can't really use it as a general purpose replacement for grep since if it doesn't find anything I'm left wondering whether what I'm searching is not really there or whether `rg` just didn't bother to check. Even with `--no-ignore --all`, I'm still not sure whether it searches everything. It's one of those tools that I find is too clever for my own good.

So when `git grep` doesn't cover my use case, my fall back is `find | grep` which contains no magic and I know exactly what it's searching.

In particular, ’rg ‐uuu’ should search the same exact content as ’grep ‐r’.

Thank you. This inspired me to read the ripgrep man page. I think I must have been confusing ripgrep's behavior with the earlier ack (or maybe ag) tool which only searched known extensions by default. I see now that ripgrep only does that if explicitly given a --type option.

Whoa, I didn't even know about `git grep`. Sure enough, `man git-grep` has a bunch of relevant info! Thanks for sharing this.

I feel like there are a billion features in git (like this) that I don't know about.

It’s handy if you want to search more than one repo at once. I believe you can do ‘rg -uuu’ as a shorthand to disable all ignores

This. Also you can do stuff like «rg —python myvariable» to search python files only. Neat for multi-language directory trees. (Works with many other languages.)

Do you know about “git grep”? It’s like grep but only greps files tracked by git. Very useful.

Why use a git-specific tool when a generic one (rg) works just as well, even from a parent directory?

I often use rg to search code across repositories so it's useful to have that regardless of grep and git

Often a directory contains a mix of source files (in git) and output files (usually in .gitignore). But maybe rg automatically handles this?

It does

I didn't, seems worth giving a look.

> It has sane defaults but you can tweak this with a .rgignore file, which is like .gitignore but for rg. By the way, it will use .gitignore files in a git directory.

Fwiw there’s also a « .ignore » semi-standard which works with several tools, and not just greps e.g. fd also respects it by default.

I use ripgrep all the time but I sometimes don't trust the results and I have been bitten too many times by heuristics it automatically uses to detect binary files and skip searching into those. These days I run ripgrep with alias `rg --color always --no-mmap -a` but still I think its binary file detection is wonky. I might be missing some relevant option but out of box - IMO grep is slower but always does what is told (and hence more reliable).

Can you give a specific example of where the binary file detection is wonky? It should be basically the same as what GNU grep does. It just looks for a NUL byte. If it exists, it's classified as binary data. Otherwise, text.

GNU grep also does binary detection by default. You have to opt into -a/--text there too. So maybe GNU grep doesn't always do what it's told either. :-)

Ah, that makes sense. I'm glad you brought that up because I didn't even notice that I'm just used to adding -R to my grep commands when I need recursive searching.

I can totally see how that would be a small, but impactful difference.

Whenever you normally use some programs with other options than their defaults, it is simpler to define aliases for those programs.

There are many common programs that I never use with their standard default options (which are very bad, IMO), e.g. cp, mv, ln, rm, rsync, date and many others, so I always define aliases for them, which include those options that I want to use by default.

So for grep, the recursive search should be included in the grep alias. There is no need for a new program in order to have this feature.

> Whenever you normally use some programs with other options than their defaults, it is simpler to define aliases for those programs.

I don't buy into this. These aliases tend to come at the cost, or at least the risk, that your workflow breaks when you are at another computer or working on a shell on some server that doesn't have this alias. That's why I like additional aliases, like l for ls, but with your favorite options. But I dislike aliases that change default behavior - and often in an intransparent way.

ripgrep adds more than "recursive search by default." And it specifically adds things that you cannot easily put into an alias.