Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$HOME/.gitignore is incorrectly used when searching in other directories such as /tmp #934

Closed
joshunger opened this issue Jun 2, 2018 · 10 comments
Labels
bug A bug.

Comments

@joshunger
Copy link

joshunger commented Jun 2, 2018

What version of ripgrep are you using?

ripgrep 0.8.1
-SIMD -AVX

How did you install ripgrep?

 brew install ripgrep

What operating system are you using ripgrep on?

mac 10.13.4

Describe your question, feature request, or bug.

Create a .gitignore in your $HOME directory. Cd over to /tmp, mkdir a pattern excluded in .gitignore and execute rg.

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

echo "*.apk" > ~/.gitignore
cd /tmp
touch foo.apk
rg --debug --files
DEBUG/grep::search/grep/src/search.rs:195: regex ast:
Repeat {
    e: Literal {
        chars: [
            'z'
        ],
        casei: false
    },
    r: Range {
        min: 0,
        max: Some(
            0
        )
    },
    greedy: true
}
DEBUG/globset/globset/src/lib.rs:401: built glob set; 0 literals, 0 basenames, 1 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
DEBUG/ignore::walk/ignore/src/walk.rs:1428: ignoring ./.keystone_install_lock: Ignore(IgnoreMatch(Hidden))
DEBUG/ignore::walk/ignore/src/walk.rs:1428: ignoring ./foo.apk: Ignore(IgnoreMatch(Gitignore(Glob { from: Some("/Users/junger/.gitignore"), original: "*.apk", actual: "**/*.apk", is_whitelist: false, is_only_dir: false })))

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

See above.

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

ripgrep should not use .gitignore in your $HOME directory when searching in other directories such as /tmp

@joshunger joshunger changed the title .gitignore is used in $HOME when searching in other directorys such as /tmp $HOME/.gitignore is not ignored when searching in other directorys such as /tmp Jun 2, 2018
@joshunger joshunger changed the title $HOME/.gitignore is not ignored when searching in other directorys such as /tmp $HOME/.gitignore is incorrectly used when searching in other directorys such as /tmp Jun 2, 2018
@joshunger joshunger changed the title $HOME/.gitignore is incorrectly used when searching in other directorys such as /tmp $HOME/.gitignore is incorrectly used when searching in other directories such as /tmp Jun 2, 2018
@BurntSushi
Copy link
Owner

Hmm, I can't seem to reproduce this issue on master:

$ pwd
/tmp/ripgrep-934
$ echo foo > $HOME/.gitignore
$ cat $HOME/.gitignore
foo
$ touch foo bar
$ rg --files
bar
foo

@joshunger
Copy link
Author

How do I install master?

➜  /tmp mkdir ripgrep-934
➜  /tmp cd ripgrep-934 
➜  ripgrep-934 echo foo > $HOME/.gitignore
➜  ripgrep-934 cat $HOME/.gitignore
foo
➜  ripgrep-934 touch foo bar
➜  ripgrep-934 rg --files
bar
➜  ripgrep-934 

@BurntSushi
Copy link
Owner

I can't reproduce this in 0.8.1 either.

Do you have any global git configuration set? For example, if you have core.excludesFile set in your ~/.gitconfig to $HOME/.gitignore, then that might be the cause. Indeed, if I add

[core]
  excludesFile = /home/andrew/.gitignore

to my $HOME/.gitconfig, then I can reproduce the problem:

$ rg --files
bar

where my --debug output is:

DEBUG/grep::search/grep/src/search.rs:195: regex ast:
Repeat {
    e: Literal {
        chars: [
            'z'
        ],
        casei: false
    },
    r: Range {
        min: 0,
        max: Some(
            0
        )
    },
    greedy: true
}
DEBUG/globset/globset/src/lib.rs:401: built glob set; 0 literals, 1 basenames, 0 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 0 regexes
DEBUG/ignore::walk/ignore/src/walk.rs:1428: ignoring ./foo: Ignore(IgnoreMatch(Gitignore(Glob { from: Some("/home/andrew/.gitignore"), original: "foo", actual: "**/foo", is_whitelist: false, is_only_dir: false })))

This does actually seem like a bug to me. I don't think ripgrep should be applying global gitignore rules outside of a git repo.

@BurntSushi
Copy link
Owner

How do I install master?

The README has build instructions. But given my previous comment, I don't think it's necessary, assuming the issue here is indeed your global git config.

@joshunger
Copy link
Author

joshunger commented Jun 2, 2018

@BurntSushi awesome catch!

➜  ripgrep-934 git config --global -l       
hub.host=...
hub.protocol=http
hub.host=...
hub.host=...
hub.host=...
hub.host=...
core.excludesfile=~/.gitignore
➜  ripgrep-934 

I also have a ton of hub.host but that can be ignored. 🤔

I also don't recalled why this is set in excludesfile.

@BurntSushi BurntSushi added the bug A bug. label Jun 2, 2018
@roblourens
Copy link
Contributor

I don't think ripgrep should be applying global gitignore rules outside of a git repo.

Even inside a git repo, this might be confusing for the same reasons that led me to use --no-ignore-parent in vscode. If it still uses global gitignore rules in git repos, it would be nice to be able to disable that.

BurntSushi added a commit that referenced this issue Jul 22, 2018
This commit adds a new --no-ignore-global flag that permits disabling
the use of global gitignore filtering. Global gitignores are generally
found in `$HOME/.config/git/ignore`, but its location can be configured
via git's `core.excludesFile` option.

Closes #934
@BurntSushi
Copy link
Owner

This bug is fixed on master, and @roblourens I've added a new --no-ignore-global flag that should do what you want!

@joshunger
Copy link
Author

Thanks @BurntSushi !

@roblourens
Copy link
Contributor

Thanks, reopening the vscode issue to use it.

@sgraham
Copy link

sgraham commented Nov 27, 2018

In case anyone else lands here and was using this as a "feature" (with apologies for the xkcd.com/1172/):

I had been using this bug to add a local .gitignore at the root of a tree that isn't itself a git repo to ignore additional things inside child git repos. Renaming .gitignore to .rgignore restores the previous behaviour.

BurntSushi added a commit that referenced this issue Feb 17, 2020
This flag prevents ripgrep from requiring one to search a git repository
in order to respect git-related ignore rules (global, .gitignore and
local excludes). This actually corresponds to behavior ripgrep had long
ago, but #934 changed that. It turns out that users were relying on this
buggy behavior. In most cases, fixing it as simple as converting one's
rules to .ignore or .rgignore files. Unfortunately, there are other use
cases---like Perforce automatically respecting .gitignore files---that
make a strong case for ripgrep to at least support this.

The UX of a flag like this is absolutely atrocious. It's so obscure that
it's really not worth explicitly calling it out anywhere. Moreover, the
error cases that occur when this flag isn't used (but its behavior is
desirable) will not be intuitive, do not seem easily detectable and will
not guide users to this flag. Nevertheless, the motivation for this is
just barely strong enough for me to begrudgingly accept this.

Fixes #1414, Closes #1416
BurntSushi added a commit that referenced this issue Feb 17, 2020
This flag prevents ripgrep from requiring one to search a git repository
in order to respect git-related ignore rules (global, .gitignore and
local excludes). This actually corresponds to behavior ripgrep had long
ago, but #934 changed that. It turns out that users were relying on this
buggy behavior. In most cases, fixing it as simple as converting one's
rules to .ignore or .rgignore files. Unfortunately, there are other use
cases---like Perforce automatically respecting .gitignore files---that
make a strong case for ripgrep to at least support this.

The UX of a flag like this is absolutely atrocious. It's so obscure that
it's really not worth explicitly calling it out anywhere. Moreover, the
error cases that occur when this flag isn't used (but its behavior is
desirable) will not be intuitive, do not seem easily detectable and will
not guide users to this flag. Nevertheless, the motivation for this is
just barely strong enough for me to begrudgingly accept this.

Fixes #1414, Closes #1416
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug.
Projects
None yet
Development

No branches or pull requests

4 participants