Previously, when importing multiple nested ignore files, some info from
the parent—notably the "root" path—would be inherited. This lead to some
problems with matching of "pseudo-absolute" rules (those with a leading
slash) in nested ignore files (see #745 for more details). To fix this,
we now fully isolate each path of the tree during the import process.
This leads to more accurate, though unfortunately slightly less
performant, rule matching. The only time a builder is reused now is if
two input files have the same `applies_in` value, in which case they are
merged together.
I have added tests to ensure correctness and prevent a regression. I
also was careful to make sure no previous tests broke in any way (all
changes to existing tests were made in isolation, and thus are not
affected by the logic changes). As far as I can tell, the only behavior
change is that now some previously-ignored rules will now be applied,
which could, in very rare configurations, lead to files being
unintentionally ignored. However, due to the aforementioned logic bug,
those files were all ignored by git already, so I suspect the number of
people actually caught off guard by this change to be extremely low,
likely zero.
Fixes#745.
This is a release PR for **project-origins** to version **1.1.0**.
Upon merging, you will still need to manually publish the cargo crate.
```
$ cd crates/project-origins
$ cargo publish
```
To merge this release, review the changes then say:
| bors r+ p=10 |
|:-:|
This is a release PR for **project-origins** to version **1.0.0**.
Upon merging, you will still need to manually publish the cargo crate.
```
$ cd crates/project-origins
$ cargo publish
```
To merge this release, review the changes then say:
```
bors r+
```
