ripgrep
ripgrep copied to clipboard
Directory paths are ignored even if negative-ignore exists for files underneath it
Running over https://salsa.debian.org/rust-team/debcargo-conf/:
$ cat .gitignore
/build
/src/*/*
!/src/*/debian
$ rg -q copyright
$ rg -q copyright src
No files were searched, which means ripgrep probably applied a filter you didn't expect. Try running again with --debug.
1
$ rg -q copyright src/*
$ git grep -q copyright
$ git grep -q copyright src
$ git grep -q copyright src/*
Yeah, this is one of the cases where it's tough for ripgrep to behave the same as git here. I think there have been bugs reported on this issue in the past, but I can't find them.
The fundamental issue is that /src/*/*
matches src/atty
(for example), and therefore, that directory is ignored and ripgrep doesn't descend into it. So the !/src/*/debian
whitelist rule isn't even applied.
Two thoughts:
- Should
src/atty
actually match/src/*/*
? There might be some special handling going on with the trailing slash that allows it to match. Not sure. - Maybe ripgrep either needs to get smarter, or it cannot implement the optimization of avoiding to descend into directories that have been ignored.
Should src/atty actually match /src//?
No, */* is pretty explicit about only matching 2 levels down. I think this would take it further away from the behaviour of git.
Maybe ripgrep either needs to get smarter, or it cannot implement the optimization of avoiding to descend into directories that have been ignored.
I think this would be the correct approach, how about not implementing the optimisation if there exists a ! whitelist rule matching potentially anything below that directory?
how about not implementing the optimisation if there exists a ! whitelist rule matching potentially anything below that directory?
Yes, that's what I mean by "smarter." There's no infrastructure for that kind of analysis yet.
But it sounds like we should at least try to understand why src/atty
is matching src/*/*
and fix that.