ripgrep 0.9.0 (rev e86d3d95c2)
-SIMD -AVX
deb release fetched from github.
Debian testing.
Global gitignore file is not picked up if ~/.gitconfig doesn't include the reference to ignoresfile directly, but via
[include]
path = /path/to/sub-git-config
and only /path/to/sub-git-config includes
[core]
excludesfile = /home/user/.gitignore
[include]
path = ~/.gitconfig_include
As can be seen running with --debug flag on, global gitignore file is not picked up.
This is a bug, but I'm not sure when or if it will get fixed.
I'm not sure it's worth fixing this. ripgrep isn't ever going to bundle a full git configuration parser, so it's likely there will always be some kind of gap anyway.
With that said, the code for loading your git config is fairly well isolated. So if an industrious individual can find a fix for this that's simple and safe, then I'd be willing to accept a PR.
Thank you for the above clarification. I agree with closing this issue.
The ripgrep v12.1.0 documentation says "In some cases, ripgrep and git will not always be in sync in terms of which files are ignored". Currently this issue is one of those cases.
Can I understand why ripgrep does not ask the git-config executable for the location of the global excludes file? i.e. the one specified by core.excludesFile (git config --get core.excludesFile) ? Is it for execution performance reasons or safety reasons?
It seems rg already provides a workaround. Run the above and supply it to rg directly, ie.
git_global_exclude_file_memoize="$(git config --get core.excludesFile)"
rg --ignore-file="$git_global_exclude_file_memoize" ...
That work-around is pretty good. It's not strictly equivalent since --ignore-file has a lower precedence than global gitignores, although, the only thing with a lower precedence than global gitignores is --ignore-file, so I guess that works.
Otherwise, the reason for not using git itself is simply because 1) I'd rather rg didn't unconditionally spawn a sub-process for every execution and 2) it requires git to actually be installed and available for ripgrep to use it.
No idea why, but this issue is no longer reproducing for me.
Gitignore is still including additional config, yet the gitignore settings are now picked up.
v 12.0.1
ripgrep doesn't follow includes in git config files, so something else must be going on. Run ripgrep with --debug to see where the ignore rules are coming from.
Given we only manage ignores via git, would it be reasonable (read: safe) to symlink .rgignore to wherever our global gitignore file is?
I think that should be okay. It won't have the same precedence as global gitignores (global has lower precedence than rgignore), but that isn't necessarily a problem in and of itself. Just the only difference I can think of.
Cheers.
For others with similar problem - if possible stop defining custom location for core.excludesfile and use the default ~/.config/git/ignore as suggested in this SO answer.
Rg already picks that one up and all the problems go away with none of the workarounds or hacks.