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.

Sign up for GitHub

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

Jump to bottom

Don't warn for broken ignore syntax #646

Closed
bluss opened this issue Oct 21, 2017 · 4 comments
Closed

Don't warn for broken ignore syntax #646

bluss opened this issue Oct 21, 2017 · 4 comments
Labels
question An issue that is lacking clarity on one or more points.

Comments

@bluss
Copy link

bluss commented Oct 21, 2017 •
edited
Loading

Example case:

$ rg SliceRef
<some directory>/.gitignore: line 2: error parsing glob '**.DS_Store': invalid use of **; must be one path component

My idea here is that I'm interested in help searching through a hairy mess of files. The syntax errors are not interesting, in that case, it's from some checked-out code that I don't know anything about anymore.

The errant line seems to be this:

**.DS_Store
  • Ripgrep version: 0.6.0 from crates.io
@BurntSushi
Copy link
Owner

There's a little discussion on this in #373, where I in particular suggest the use of --no-messages.

I don't agree with completely suppressing gitignore errors, since I think they are useful for diagnosing .gitignore problems. Notably, git doesn't report any errors, it just silently ignores bad patterns and I've seen more than a few cases where ripgrep made folks realize that their .gitignore files were actually wrong!

@BurntSushi BurntSushi added the question An issue that is lacking clarity on one or more points. label Oct 21, 2017
@FSMaxB
Copy link

FSMaxB commented Oct 22, 2017

Quick workaround: rg SliceRef 2> /dev/null

The error messages are written to stderr, so you can just suppress them like that.

@bluss
Copy link
Author

bluss commented Oct 22, 2017

--no-messages is a good existing workaround too. I'll just research what else I might be missing with it.

@BurntSushi
Copy link
Owner

@bluss Have you amassed any more thoughts on this topic? Every time I look at this issue, I wonder how it can be closed, but I am myself torn on it. On the one hand, it surfaces invalid gitignores, on the other hand, it's frustrating if those gitignores aren't your own.

@BurntSushi BurntSushi mentioned this issue Jun 12, 2018
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question An issue that is lacking clarity on one or more points.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@BurntSushi @bluss @FSMaxB