Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Name ending with slash does not ignore recursively #9

Closed
murtzi opened this issue Sep 9, 2020 · 0 comments · Fixed by #118
Closed

Name ending with slash does not ignore recursively #9

murtzi opened this issue Sep 9, 2020 · 0 comments · Fixed by #118

Comments

@murtzi
Copy link

murtzi commented Sep 9, 2020

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:

./.ignore
./example
./example/file
./subdir
./subdir/example
./subdir/example/file

.ignore contents:

example/

walk returns: [ '.ignore', 'subdir/example/file' ]

I believe it should also ignore subdir/example to be compatible with .gitignore.
LinqLover added a commit to LinqLover/ignore-walk that referenced this issue Oct 23, 2021
@LinqLover
Fix recursive directory ignore rules
6c8e575 
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.
@LinqLover LinqLover mentioned this issue Oct 23, 2021
Closed
wraithgar pushed a commit that referenced this issue Nov 28, 2023
@LinqLover @wraithgar
Fix recursive directory ignore rules
bd6f030 
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 wraithgar mentioned this issue Nov 28, 2023
Merged
wraithgar added a commit that referenced this issue Nov 28, 2023
@wraithgar @LinqLover
fix: recursive directory ignore rules (#118)
8e9b2fd 
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
@wraithgar @LinqLover
fix: recursive directory ignore rules (#118)
c101d75 
Gets us closer to parity w/ the gitignore rules.

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
@wraithgar @LinqLover
fix: recursive directory ignore rules (#118)
493401a 
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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@murtzi