Possibly add a gitignore parser

[facelessuser]

Parsing a gitignore file is kind of a different kind o animal compared to normal globbing.

1. It is file centric.

2. It seems to operate on the files as it returns them and has behavior such that each rule is applied in order and can undo the last.

   Essentially, this would result in an included file:

   a.txt
   !a.text
   a.txt
   !a.txt
   

   This is different than how we do things currently in normal glob where the all the patterns are taken in context together.

3. When a folder is excluded, it is skipped, and you cannot reinclude it or then process files that weren't evaluated because of it.

4. There is a slightly different handling in regards to MATCHBASE. We apply base matching if there are no /, but they still apply if there is only one at the end, indicating a directory.

5. Lastly, I don't think they allow for [[:ASCII:]] posix style character classes. I'd have to check.

There are probably some other minor things, like there are rules for trailing white space and such, but that would probably be handled by the gitignore parser, once parsed into patterns, they'd be treated like normal patterns.

I imagine if we were to implement this we need to do the following things.

1. Write a parser for a gitignore buffer that returns a list of patterns.
2. Employ something similar to the WcMatch class that streams files. The class would be limited to gitignore features, no configuring of flags.
3. Provide an internal hook that modifies MATCHBASE to distinguish between trailing / vs any / within a path.
4. Possibly provide an internal hook that skips posix character classes if they are not supported (I'm pretty sure they are not).

Another approach would be maybe to have a gitignore filter. This would likely need to break a file path up during evaluation as if it its parts were being streamed from a file tree walker since that is the way gitignore is applied.

It's possible we could just integrate gitignore into the WcMatch class and it could find files as it normally does, but then using a gitignore filter, further remove files relative to the working path.

Anyways, some things to think about.

[kdeldycke]

That would be great!

I'm currently relying on gitignore_parser which somehow works for my use-case, but is unmaintained. It also doesn't work on Windows, so I had to resort on an horrible local patch.

Browsing this space, I found a collection of unittests here which can be helpful to validate this feature.

[facelessuser]

Appreciate your interest in this. Right now this is really just an idea I'm thinking about, so no promise on this feature becoming a reality or not.

One thing that gives me some pause is that I'm expecting that if/when we do this, people will expect us to match any and all quirks of gitignore. I'm not sure how it matches exactly to Bash logic, though I'm sure its fairly close, so just something to note.

[kdeldycke]

Update on the state of things: gitignore_parser is not bad but py-walk is now my preferred package as the latter fixes edge-cases of the former.

[facelessuser]

Oh, good to know. If it turns out there are decent, dedicated solutions, and a solution is not needed here, then it may not make sense for me to spend time on it here.