Name ending with slash does not ignore recursively #9
Comments
LinqLover
added a commit
to LinqLover/ignore-walk
that referenced
this issue
Oct 23, 2021
Citing from the gitignore docs [1]: > If there is a separator at the beginning or middle (or both) of the > pattern, then the pattern is relative to the directory level of the > particular .gitignore file itself. Otherwise the pattern may also > match at any level below the .gitignore level. Previously, parent walkers were only passed the resolved path to a file entry via filterEntry(). This patch also passes the entry's basename which is matched against the rule if it is relative. Regression tests are included as well. Closes npm#9. [1] http://git-scm.com/docs/gitignore#_pattern_format#:~:text=If%20there%20is%20a%20separator%20at%20the%20beginning%20or%20middle%20(or%20both)%20of%20the%20pattern%2C%20then%20the%20pattern%20is%20relative%20to%20the%20directory%20level%20of%20the%20particular%20.gitignore%20file%20itself.%20Otherwise%20the%20pattern%20may%20also%20match%20at%20any%20level%20below%20the%20.gitignore%20level.
wraithgar
pushed a commit
that referenced
this issue
Nov 28, 2023
Citing from the gitignore docs [1]: > If there is a separator at the beginning or middle (or both) of the > pattern, then the pattern is relative to the directory level of the > particular .gitignore file itself. Otherwise the pattern may also > match at any level below the .gitignore level. Previously, parent walkers were only passed the resolved path to a file entry via filterEntry(). This patch also passes the entry's basename which is matched against the rule if it is relative. Regression tests are included as well. Closes #9. [1] http://git-scm.com/docs/gitignore#_pattern_format#:~:text=If%20there%20is%20a%20separator%20at%20the%20beginning%20or%20middle%20(or%20both)%20of%20the%20pattern%2C%20then%20the%20pattern%20is%20relative%20to%20the%20directory%20level%20of%20the%20particular%20.gitignore%20file%20itself.%20Otherwise%20the%20pattern%20may%20also%20match%20at%20any%20level%20below%20the%20.gitignore%20level.
wraithgar
added a commit
that referenced
this issue
Nov 28, 2023
Citing from the [gitignore docs](http://git-scm.com/docs/gitignore#_pattern_format#:~:text=If%20there%20is%20a%20separator%20at%20the%20beginning%20or%20middle%20(or%20both)%20of%20the%20pattern%2C%20then%20the%20pattern%20is%20relative%20to%20the%20directory%20level%20of%20the%20particular%20.gitignore%20file%20itself.%20Otherwise%20the%20pattern%20may%20also%20match%20at%20any%20level%20below%20the%20.gitignore%20level.): > If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular `.gitignore` file itself. Otherwise the pattern may also match at any level below the `.gitignore` level. Previously, parent walkers were only passed the resolved path to a file entry via filterEntry()`. This patch also passes the entry's basename which is matched against the rule if it is relative. Regression tests are included as well. Closes #9. --------- Co-authored-by: Christoph Thiede <[email protected]>
wraithgar
added a commit
that referenced
this issue
Nov 29, 2023
Gets us closer to parity w/ the gitignore rules. Closes #9. --------- Co-authored-by: Christoph Thiede <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When ignore contains name ending with slash, e.g.
example/, the directory name is only excluded from top-level, not recursively.With following directory structure:
.ignorecontents:walk returns:
[ '.ignore', 'subdir/example/file' ]I believe it should also ignore
subdir/exampleto be compatible with.gitignore.The text was updated successfully, but these errors were encountered: