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

projectile-helm-ag doesn't respect .gitignore file #21

Open
mydearxym opened this issue May 11, 2016 · 6 comments
Open

projectile-helm-ag doesn't respect .gitignore file #21

mydearxym opened this issue May 11, 2016 · 6 comments

Comments

@mydearxym
Copy link

In a git project, projectile-helm-ag searches files and directories in .gitignore.

see bbatsov/projectile#709

@Cbeck527
Copy link

Any updates on this issue?

@amithgeorge
Copy link

I came across this bug. In my case, it only respects the top most .gitignore. If I have a .gitignore inside some directory with additional rules, then those files are not excluded from the search.

/root
 - .git
 - .gitignore //// these rules are respected
 - /some-dir
    - .gitignore //// the rules here are not respected

For the time being I copied the rules over from the inner gitignore to the outer one.

@xiongtx
Copy link
Collaborator

xiongtx commented Feb 3, 2017

To ignore files, you can use the .projectile file at the project root.

I'll look into a more complete solution, but there's no ETA.

@Cbeck527
Copy link

Cbeck527 commented Feb 4, 2017

What indexing method do you use? I think that I saw this bug go away after adding this to my init file:

(setq projectile-indexing-method 'git)

Though this could be a red herring... it's still unclear to me.

@rileyrg
Copy link

rileyrg commented Jan 28, 2020

I want helm-projectile-ag to search in .gitignored directories. How do I do this?

@arichiardi
Copy link

arichiardi commented Aug 23, 2024

I have done a bit of debugging and this is the full command line this plugin sends to ag in my project (function is helm-projectile-ag and binding helm-ag-base-command:

ag --nocolor --nogroup --ignore-case --ignore TAGS --ignore .#* --ignore *.cmti --ignore *.cmt --ignore *.annot --ignore *.cmi --ignore *.cmxa --ignore *.cma --ignore *.cmx --ignore *.cmo --ignore *.o --ignore *~ --ignore *.bin --ignore *.lbin --ignore *.so --ignore *.a --ignore *.ln --ignore *.blg --ignore *.bbl --ignore *.elc --ignore *.lof --ignore *.glo --ignore *.idx --ignore *.lot --ignore *.fmt --ignore *.tfm --ignore *.class --ignore *.fas --ignore *.lib --ignore *.mem --ignore *.x86f --ignore *.sparcf --ignore *.dfsl --ignore *.pfsl --ignore *.d64fsl --ignore *.p64fsl --ignore *.lx64fsl --ignore *.lx32fsl --ignore *.dx64fsl --ignore *.dx32fsl --ignore *.fx64fsl --ignore *.fx32fsl --ignore *.sx64fsl --ignore *.sx32fsl --ignore *.wx64fsl --ignore *.wx32fsl --ignore *.fasl --ignore *.ufsl --ignore *.fsl --ignore *.dxl --ignore *.lo --ignore *.la --ignore *.gmo --ignore *.mo --ignore *.toc --ignore *.aux --ignore *.cp --ignore *.fn --ignore *.ky --ignore *.pg --ignore *.tp --ignore *.vr --ignore *.cps --ignore *.fns --ignore *.kys --ignore *.pgs --ignore *.tps --ignore *.vrs --ignore *.pyc --ignore *.pyo --ignore {arch} --ignore _darcs --ignore _MTN --ignore .bzr --ignore .hg --ignore .git --ignore .svn --ignore .src --ignore MCVS --ignore CVS --ignore RCS --ignore SCCS --ignore node_modules/ --ignore target/ --ignore logs/ --ignore ^\.idea$/ --ignore ^\.vscode$/ --ignore ^\.ensime_cache$/ --ignore ^\.eunit$/ --ignore ^\.git$/ --ignore ^\.hg$/ --ignore ^\.fslckout$/ --ignore ^_FOSSIL_$/ --ignore ^\.bzr$/ --ignore ^_darcs$/ --ignore ^\.pijul$/ --ignore ^\.tox$/ --ignore ^\.svn$/ --ignore ^\.stack-work$/ --ignore ^\.ccls-cache$/ --ignore ^\.cache$/ --ignore ^\.clangd$/ 

The initial TAGS comes from (projectile-ignored-files-rel) the rest from (projectile-ignored-directories-rel). the above --ignore do not correspond to the contents of my project root's .gitignore.

Can it be that passing --ignore actually tells ag not to use the default .gitignore?

EDIT: if that's the case a defcustom that disables adding projectiles ignores would solve the problem...

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

No branches or pull requests

6 participants