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

Option to consider only parent .rgignore files? #53

Closed
kaushalmodi opened this issue Sep 24, 2016 · 5 comments
Closed

Option to consider only parent .rgignore files? #53

kaushalmodi opened this issue Sep 24, 2016 · 5 comments

Comments

@kaushalmodi
Copy link
Contributor

I have a ~/.gitignore and that is considered as an ignore file for everything in my $HOME. In my use case the contents of ~/.gitignore do not apply as ignore criteria for searches! I have ~/.gitignore set up just to prevent committing sensitive text files to git (and then push) by mistake. So that file contains something like

a*
!a_ok_to_commit

That would prevent search of all a* files everywhere in my $HOME.

So it would be great to allow parent .rgignore (only) file consideration.

In addition a .gitignore specific -u would also be needed.

In summary, there is very little overlap of the contents of .gitignore and search ignore files like .agignore and .rgignore.

For .gitignore:

  • Never use that for search ignores
  • Do not use parent .gitignore

For .rgignore:

  • Use that for search ignores
  • Use parent .rgignore files

From what I understand, right now -u and --no-ignore-parent applies to both of these files and you cannot set those options separately for those 2 files.

@BurntSushi
Copy link
Owner

BurntSushi commented Sep 24, 2016

Why not just whitelist the files you want to search in your ~/.rgignore? e.g., !a*.

(I think I had the same problem as you, so I just put !* in my $HOME/.rgignore, which whitelists anything that would otherwise be ignored by $HOME/.gitignore.)

@kaushalmodi
Copy link
Contributor Author

kaushalmodi commented Sep 24, 2016

Before whitelisting:

km²~/temp/:proj> rg foo --debug                                                                                                                                                                      09/24 1:26am
DEBUG:grep::search: regex ast:
Literal {
    chars: [
        'f',
        'o',
        'o'
    ],
    casei: false
}
DEBUG:grep::literals: literal prefixes detected: Literals { lits: [Complete(foo)], limit_size: 250, limit_class: 10 }
DEBUG:rg::ignore: ./SOMEPRJ/abc ignored by Pattern { from: "/home/kmodi/.gitignore", original: "a*", pat: "**/a*", whitelist: false, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/ghi ignored by Pattern { from: "/home/kmodi/.gitignore", original: "g*", pat: "**/g*", whitelist: false, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/.rgignore ignored because it is hidden
No files were searched, which means ripgrep probably applied a filter you didn't expect. Try running again with --debug.

After whitelisting by add !* to the very top of ~/.rgignore:

km²~/temp/:proj> rg foo --debug                                                                                                                                                                      09/24 1:31am
DEBUG:grep::search: regex ast:
Literal {
    chars: [
        'f',
        'o',
        'o'
    ],
    casei: false
}
DEBUG:grep::literals: literal prefixes detected: Literals { lits: [Complete(foo)], limit_size: 250, limit_class: 10 }
DEBUG:rg::ignore: ./SOMEPRJ whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/abc whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/abc/def whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/abc/def/XXX whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/abc/def/XXX/YYY whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/abc/def/XXX/YYY/bar whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/ghi whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/ghi/XXX whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/ghi/XXX/YYY whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/ghi/XXX/YYY/bar whitelisted by Pattern { from: "/home/kmodi/.rgignore", original: "!*", pat: "**/*", whitelist: true, only_dir: false }
DEBUG:rg::ignore: ./SOMEPRJ/.rgignore ignored because it is hidden
SOMEPRJ/abc/def/XXX/YYY/bar
1:foo

SOMEPRJ/ghi/XXX/YYY/bar
1:foo

I believe this works (just that this repeats the bug in #50).

Thanks,

I only concern is that if you implement a global ignore file in $HOME/ripgrep/ignore ( #45 ), then how would the priority work?

Then I would need to put !* in $HOME/ripgrep/ignore that would override the ignores in ~/.gitignore? But wouldn't that be the wrong order?

On the other hand, if I put !* in ~/.rgignore, then wouldn't that override all the ignores in $HOME/ripgrep/ignore? :)

@BurntSushi
Copy link
Owner

It seems like the priority of any "global" ignores file should come strictly after any ignores from inside parent directories are considered. If you want to override ~/.gitignore then it makes sense that you should use a ~/.rgignore to do it.

@BurntSushi
Copy link
Owner

It sounds like this use case should be solved either by a global ignore file (#45) or by using explicit per-directory overrides.

@kaushalmodi
Copy link
Contributor Author

This issue was more related to #68.

The fix for that issue ( 8eeb0c0 ) fixes this issue too.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants