.gitignore lines should be used instead of ls-files output in the right circumstances

[mikewadsten]

Problem statement

If g:gitwildignore_use_ls_files is set to 1, then wildignore will contain the full path to every ignored file. For small repositories (maybe a dozen or so ignored files) this isn't much of a problem, but for larger repos it will almost certainly become a problem, especially when ignoring things like .pyc files.

Solution

As an optimization, vim-gitwildignore might do the following:

1. Read in all .gitignore files
2. Use git ls-files... to find all the ignored files and directories.
3. If there are no negations in the .gitignore files, then:
   1. Add each ignored directory to wildignore (corresponding to the implementation in 4c9144f)
   2. For each ignored file (ls-files output), find the ignore pattern that matches it and add it to a list.
      • Might need to do something clever to find the closest/last match (i.e. later in the files)
   3. Make sure that list only contains one of each element (or just treat the list as a set to begin with), and add that list, joined with commas, to wildignore.
4. If there are negations in the list, then:
   • If some option (e.g. g:gitwildignore_skip_negations) says to ignore negations, goto 3.i.
   • Else, TBD

---

(3.ii and 3.iii can more or less be boiled down to "add every file ignore from .gitignore files to wildignore, especially since that means that even ignores which aren't used right now (like *.o when you haven't run make) are in place.)

The gist of this idea is so that if you're using an ignore like *.pyc, and nothing negates that ignore, then just plug *.pyc (or [git root]/**/*.pyc?) into wildignore, rather than adding each and every .pyc file. This will cut down on the length of the wildignore value.