-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Surprising application of .gitignore in rust-lang/rust repo #25
Labels
bug
A bug.
Comments
According to
So I think your expectation is correct, that it should match relative to the location of the file, not the current directory. |
It is indeed a plain ol' bug. |
This was referenced Sep 24, 2016
Closed
amsharma91
added a commit
to amsharma91/ripgrep
that referenced
this issue
Sep 27, 2016
If a gitignore file in a *parent* directory is used, then it must be matched relative to the directory it's in. ripgrep wasn't actually adhering to this rule. Consider an example: .gitignore src llvm foo Where `.gitignore` contains `/llvm/` and `foo` contains `test`. When running `rg test` at the top-level directory, `foo` is correctly searched. If you `cd` into `src` and re-run the same search, `foo` is ignored because the `/llvm/` pattern is interpreted with respect to the current working directory, which is wrong. The problem is that the path of `llvm` is `./llvm`, which makes it look like it should match. We fix this by rebuilding the directory path of each file when traversing gitignores in parent directories. This does come with a small performance hit. Fixes BurntSushi#25.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This may be working as designed but it was quite surprising. If I run
rg LLVM_BINDINGS
from the top level of the rust repo I get results. If I do the same fromsrc/
I get no results. The reason is that rust's .gitignore file contains/llvm/
.Perhaps this is how .gitignore is defined to work, but it's not what I expected. I might expect that .gitignore would by applied relative to the directory in which it is defined.
The text was updated successfully, but these errors were encountered: