Ripgrep: gitignore not used if excludesfile is added via [include] block

Created on 14 Aug 2018  路  9Comments  路  Source: BurntSushi/ripgrep

What version of ripgrep are you using?

ripgrep 0.9.0 (rev e86d3d95c2)
-SIMD -AVX

How did you install ripgrep?

deb release fetched from github.

What operating system are you using ripgrep on?

Debian testing.

Describe your question, feature request, or bug.

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

If this is a bug, what are the steps to reproduce the behavior?

  1. move all your ~/.gitconfig content to ~/.gitconfig_include
  2. replace ~/.gitconfig contents with
[include]
    path = ~/.gitconfig_include
  1. search for content/file that includes files matched by your ~/.gitignore
  2. rg returns the file you expected to be ignored

If this is a bug, what is the actual behavior?

As can be seen running with --debug flag on, global gitignore file is not picked up.

bug

All 9 comments

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.

Was this page helpful?
0 / 5 - 0 ratings