If I run Ctrl-P natively out of the box, it works 100% as I desire, except that with the size of the codebase I work with, it takes a very long time to index directories.
To make Ctrl-P cope with the project sizes I'm dealing with, I'm using the following (fairly popular) user_command setting in my .vimrc file to provide native helper-utilities to more quickly provide Ctrl-P with the list of files available:
if has("unix")
let g:ctrlp_user_command = {
\ 'types': {
\ 1: ['.git/', 'cd %s && git ls-files']
\ },
\ 'fallback': 'find %s -type f | head -' . g:ctrlp_max_files
\ }
endif
This approach makes indexing blazingly fast, but when configured this way Ctrl-P doesn't learn about the contents of git submodules the way that it did when running without helper programs (since 'git ls-files' doesn't recurse into submodules, while Ctrl-P's naive directory traversal does).
I've tried using 'find' to index git repositories as well, but when I do that I wind up indexing .git directories, object files, and all sorts of other things that Ctrl-P normally knows to ignore automatically; seems like providing a user_command completely supersedes the built-in logic about which files to ignore. I could probably hack together an inverse grep to remove certain elements, but it seemed like someone must have figured out a more elegant solution to this.
Is there another, perhaps cleverer way to get Ctrl-P to index all files within a git repository, including the files inside all its submodules, other than resorting to its slow built-in search?
You could use find with options to filter out file you don't want like :
find . -type f \( -name "*.cpp" -or -name "*.h" \)
or removing .git directories :
find . -path '.git' -prune -o -print
but this is not a smart solution.