Ripgrep: add flag to specify one or more additional ignore files

Hmm. Would you be opposed to this going in $XDG_CONFIG_HOME/ripgrep/ignore? That way, we won't need to specify any weird interaction between the current semantics, which are "obeys parent directory .ignore files," and the new semantics, which if we did what you suggested would be, "obeys parent directory unless $HOME/.ignore exists, in which case, it's used everywhere." $XDG_CONFIG_HOME feels a bit more right.

I am on RHEL6.6 and echo $XDG_CONFIG_HOME returns

XDG_CONFIG_HOME: Undefined variable.

Also this is work machine.. so I don't have admin rights. Do we have an xdg alternative in that case?

Sorry, by $XDG_CONFIG_HOME, I meant "follow the XDG basedir spec." Specifically, if XDG_CONFIG_HOME isn't set, then it defaults to $HOME/.config.

Hmm, I symlinked $HOME/.config/ripgrep/ignore to ~/.agignore. I also tried few other symlink names. But none helped.. The files ignored in ~.agignore are still being searched.

km²~/.config/:ripgrep> lta                                                        
total 8.0K
drwxr-xr-x 28 kmodi users 4.0K Sep 24 00:48 ../
lrwxrwxrwx  1 kmodi users   21 Sep 24 00:52 .rpignore -> /home/kmodi/.agignore
lrwxrwxrwx  1 kmodi users   21 Sep 24 00:52 .ignore -> /home/kmodi/.agignore
lrwxrwxrwx  1 kmodi users   21 Sep 24 00:52 ignore -> /home/kmodi/.agignore
drwxr-xr-x  2 kmodi users 4.0K Sep 24 00:52 ./
km²~/.config/:ripgrep> pwd                                                             
/home/kmodi/.config/ripgrep
km²~/.config/:ripgrep> 

Well, $HOME/.config/ripgrep/ignore functionality doesn't exist. I was proposing it and asking if it would satisfy your use case. :-)

Ah OK, that would work as long as I can maintain just one common global ignore file :)

Thanks!

Here's another idea to implement the same. I like it better because then I use an alias to have the complete rg configuration control.

How about having a switch named --ignore-file. Here's a spec suggestion for that:

--ignore-file FILE: Read the .ignore file FILE before reading the .ignore, .gitignore, etc. in the current or parent directories. Multiple --ignore-file flags may be used.

When you say "Read the ignore file before reading .ignore .gitignore in current or parent directories," do you mean that --ignore-file takes precedence over them? (In contrast, I'd expect .ignore/.gitignore to take precedence over a global config file.)

do you mean that --ignore-file takes precedence over them?

No, here was my thinking..

Let's use we did rg --ignore-file ~/.ignore foo and suppose we had:

$ cat ~/.ignore
*.log

Suppose we had a /proj and

$ cat /proj/.ignore
!imp.log

Then if ~/.ignore (FILE arg to --ignore-file) is read first, /proj/.ignore will be able to white-list some part out of the ignore set by the previously read file _if we are running rg --ignore-file ~/.ignore foo from the /proj directory._

So, _read first_ implies _open to be overridden_.

@kaushalmodi Hmm, yes, I see, I think those semantics makes sense.

FWIW the_silver_searcher uses --path-to-ignore SOMEPATH and the file name used is (as of 0.33.0) .ignore

Allowing multiple --ignore-file becomes even more useful as I see an application where I can have a central .ignore file for the whole project (version controlled), and then users can add their specific .ignore files on top of that if they wish.

@kaushalmodi I definitely like the idea of --ignore-file (allowing multiple uses) better than a global ignore file. If we just add that, does that satisfy your use case?

If we just add that, does that satisfy your use case?

Absolutely! Then I need to simply add that to my alias and then it becomes as good as a global ignore file. What's even better is that I can have more than one global ignores.. one that is central to the whole project, others which could be user-specific.

Perfect. Much easier to implement. Hopefully tonight. :-)

Thanks! Just to confirm that they will have the lowest priority when compared with the ones in the current/parent directories as in my example above, correct?

Yes. The terminology I'd like to use is "precedence." That is, ignore files specified via --ignore-file have a lower precedence than any other ignore file. That means a whitelisted pattern in an ignore file in a directory will override an ignore pattern in an --ignore-file.

This is slightly trickier than I thought and probably exceeds my budget for middle-of-the-week work unfortunately. The issue is that every ignore file needs to interpret paths relative to _itself_ (these are the semantics of .gitignore, and frankly, nothing else really makes much sense), and current ignore code makes this a little tricky. I'm happy to hack this in because I have plans to overhaul the ignore code anyway, but it requires a bit more attention than I'm capable of right now.

I hope that the overhaul in the globbing code now makes it possible to implement this.

No. The ignore code and the glob code are related but distinct. Sorry.

Refactoring the ignore code is pretty high on my list because I hope to get perf gains out of it.

I just got married. I'll get to this when I can.

I just got married. I'll get to this when I can.

Understood. Congratulations! :)

Fixed in #202.