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
Doesn't respect "match-beginning" gitignore patterns in subdirs #285
Comments
What filesystem are you using to test this? Is this affected by a similar problem to issue #275? |
This is on OS X, so HFS+. While initially attempting to create "steps to reproduce" as above, I certainly noticed something strange, whereby the presence of one file seemed to affect the "searchability" of another, but I unfortunately neglected to note my actions or the exact details. That behaviour does sound related to #275. |
Can you try pull request #284 to see if it helps at all? |
Yep, I can hopefully give that a try later today. |
Fix ggreer#285 but needs testing for more complex directories
Bah, having a non-trivial time getting this to compile here on my Mac. Do you happen to know the magic |
I don't have OSX so I'm not sure I can help. I'd have thought pkg-config would have taken the strain. Have you installed the dependencies from the build section of the README.md and run ./build.sh? Beyond that, ./configure can accept variables like |
Thanks. No, |
Okay, got it built -- sorry for the noise. So PR #284 doesn't fix this specific problem: the |
Fix ggreer#285 but needs testing for more complex directories
Hmm. That's odd. #284 works on Linux on both hfsplus and ntfs filesystems here. I'm sure this patch is getting close to the nub of the problem. I can't quite get my head around the recursion and appropriate manipulation of scandir_baton->level and ig->parent to do the right thing. I'll keep playing with files until it breaks again so I can debug it further. |
Fix ggreer#285 but needs testing for more complex directories
Can you try the current version of #284 and see if it fixes your problem? |
I updated to the latest version of the PR (7f4f4d1) and nope, it still doesn't ignore |
Back to the drawing board! To be honest, I'm struggling here. It is working fine on Linux with various filesystems and I don't think I'm going to be able to take it further without running the debugger on a Mac. I wonder if the problem is even more esoteric. Is there a difference in pcre? Perhaps some difference in the Linux and Mac implementations in HFS+? (Or, more likely, my code just stinks...!) |
I'll dig into the code myself when I get a chance and see if I can figure things out. Would be nice to have a simple shell-scripted test suite for the various exclusion patterns etc. |
Does the ignore still fail if you remove the asterisks from the .gitignore patterns? |
You know, scratch that -- your fix works. I was picking up the wrong ag in my environment. |
Sorry. |
Now all of the following patterns correctly ignore
|
Ha! Great. |
Hi folks! This fix has been published somewhere? |
great, thanks! |
Fix ggreer#285 but needs testing for more complex directories
Fix ggreer#285 but needs testing for more complex directories
Fix ggreer#285 but needs testing for more complex directories
Attempt to fix issue 275 Only increment the scandir baton when recursing Fix ggreer#285 but needs testing for more complex directories Check ignore paths based on correct baton level Fix ggreer#287 but doesn't fix ggreer#144 Stop comparing terminating NULL in path string Might save a few cycles... Handle absolute .gitignore patterns properly Pattern /b/c/d should ignore /b/c/d but not a/b/c/d
Attempt to fix issue 275 Only increment the scandir baton when recursing Fix ggreer#285 but needs testing for more complex directories Check ignore paths based on correct baton level Fix ggreer#287 but doesn't fix ggreer#144 Stop comparing terminating NULL in path string Might save a few cycles... Handle absolute .gitignore patterns properly Pattern /b/c/d should ignore /b/c/d but not a/b/c/d
Attempt to fix issue 275 Only increment the scandir baton when recursing Fix ggreer#285 but needs testing for more complex directories Check ignore paths based on correct baton level Fix ggreer#287 but doesn't fix ggreer#144 Stop comparing terminating NULL in path string Might save a few cycles... Handle absolute .gitignore patterns properly Pattern /b/c/d should ignore /b/c/d but not a/b/c/d
I assume this hasn't been fixed yet in any released version? Got slightly confused when ag started acting weird after making a change to gitignore. More specifically, replaced |
Ok, I just submitted a duplicate bug for this.. |
Attempt to fix issue 275 Only increment the scandir baton when recursing Fix ggreer#285 but needs testing for more complex directories Check ignore paths based on correct baton level Fix ggreer#287 but doesn't fix ggreer#144 Stop comparing terminating NULL in path string Might save a few cycles... Handle absolute .gitignore patterns properly Pattern /b/c/d should ignore /b/c/d but not a/b/c/d
Attempt to fix issue 275 Only increment the scandir baton when recursing Fix ggreer#285 but needs testing for more complex directories Check ignore paths based on correct baton level Fix ggreer#287 but doesn't fix ggreer#144 Stop comparing terminating NULL in path string Might save a few cycles... Handle absolute .gitignore patterns properly Pattern /b/c/d should ignore /b/c/d but not a/b/c/d
Attempt to fix issue 275 Only increment the scandir baton when recursing Fix ggreer#285 but needs testing for more complex directories Check ignore paths based on correct baton level Fix ggreer#287 but doesn't fix ggreer#144 Stop comparing terminating NULL in path string Might save a few cycles... Handle absolute .gitignore patterns properly Pattern /b/c/d should ignore /b/c/d but not a/b/c/d
Attempt to fix issue 275 Only increment the scandir baton when recursing Fix ggreer#285 but needs testing for more complex directories Check ignore paths based on correct baton level Fix ggreer#287 but doesn't fix ggreer#144 Stop comparing terminating NULL in path string Might save a few cycles... Handle absolute .gitignore patterns properly Pattern /b/c/d should ignore /b/c/d but not a/b/c/d
I also filed a duplicate of this issue a while back (#595). FWIW, I wrote a patch to the cram tests that illustrates the problem, and could be handy in verifying a future fix: https://github.com/ctrueden/the_silver_searcher/commit/4f1399723ecb6db069af455b2f37ee38b7e3ddab |
I can also confirm the issue. And another problem that I think it's still related to the .gitignore file is a case where you ignore a entire folder but some files as exemplified by the following hypothetical .gitigore:
If I search for some content the file ignored/not_ignored will not be included in the files for the search. |
This fix has still not been merged in, correct? |
@bdesham I don't think anyone has actually submitted a patch that fixes this... have they? |
I'm afraid there have been layers of breakage added to the ignore code since I made that patch, so there is no way I could keep it rebased against upstream. You can use my fork if you want to try the code. It isn't perfect, but I'm sure some enterprising soul could fix the edge cases where it breaks. |
Can confirm the issue. It's a really painful having ag go through dist assets -- which are commonly exempted from version control via "/dist" in the .gitignore file. |
because ag picks up too many dist + node_module files: ggreer/the_silver_searcher#285 (and possibly no longer maintained?)
In
.gitignore
files, ignore patterns can be prefixed with a "/".man gitignore
says:ag
currently doesn't apply such patterns when they match files in subdirectories. Steps to reproduce:However, the non-subdir case currently works correctly:
Other than this minor hiccup, it's awesomeness all the way. :-)
The text was updated successfully, but these errors were encountered: