How much trouble would it be to implement searching all git branches in all repos in the path being searched?

[shabbir-genetech]

Hi @BurntSushi ,

Big fan of ripgrep's performance here.

So, I have this like feature request. I could try to implement it myself if you could provide some guidance as to where the code would need to go and what would it look like.

Basically, I am lazy. I have a bunch of repos spread across my 'home' directory (I use Windows). When I want to find something, I open up cmd and ripgrep it from the home dir. Given rg's performance, it's faster to let the machine figure out where and which repo I'm interested in working on.

Problem is, sometimes what I am searching for is not in the currently checked out branch/working tree. So, how difficult would it be to search each branch, each stash and the git index and head for each repo encountered in the path being searched?

What would the performance implications be? Would it be easy to implement?

Thanks.

[BurntSushi]

So I think I'll just say up-front that I don't think this feature is a good fit for ripgrep. It's not that it's necessarily hard to implement, but fitting it into the existing model and making sure all of the CLI flags make sense is probably pretty tricky. Moreover, this is kind the of feature that would rapidly beget more features. You would need all kinds of git-specific filtering logic to be added to support the likely very varied number of use cases people would come up with. I personally need to balance such things against my ability to maintain the project effectively give the resources I have.

With that said, I'd be happy to elaborate a bit on how I'd solve this problem. In particular, solving this problem for a particular person's use case is probably much much easier than solving it for all users of ripgrep.

Personally, I would point you toward git grep. You can use it to search arbitrary revisions of a specific repository. For example, this searches my current checkout:

$ git grep 'fn is_empty'
crates/globset/src/lib.rs:    pub fn is_empty(&self) -> bool {
crates/ignore/src/gitignore.rs:    pub fn is_empty(&self) -> bool {
crates/ignore/src/overrides.rs:    pub fn is_empty(&self) -> bool {
crates/ignore/src/types.rs:    pub fn is_empty(&self) -> bool {
crates/matcher/src/lib.rs:    pub fn is_empty(&self) -> bool {
crates/matcher/src/lib.rs:    fn is_empty(&self) -> bool {

While this searches an ancient version of ripgrep:

$ git grep 'fn is_empty' 0.3.0
0.3.0:globset/src/lib.rs:    pub fn is_empty(&self) -> bool {
0.3.0:ignore/src/gitignore.rs:    pub fn is_empty(&self) -> bool {
0.3.0:ignore/src/overrides.rs:    pub fn is_empty(&self) -> bool {
0.3.0:ignore/src/types.rs:    pub fn is_empty(&self) -> bool {
0.3.0:termcolor/src/lib.rs:    pub fn is_empty(&self) -> bool {

It would be quite a lot of work for ripgrep to replicate this behavior as seamlessly as git grep does. In particular, git grep doesn't need to checkout any files to do this search. It can search directly against the git index. Which means if ripgrep wanted to do the same, it would need to grow git-specific searching functionality, probably by using libgit2 for example.

There's more info here: https://stackoverflow.com/questions/2928584/how-to-grep-search-committed-code-in-the-git-history

In terms of "I just want to search my home directory and have it search every repo and every branch," I think I would just write a custom shell script that did this for me. It shouldn't be hard to find all of your git repos, and at that point, you can just run git grep for each of them.