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.

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

files inside an ignored sub-directory are not matched #19

Closed
spMohanty opened this issue Mar 18, 2018 · 5 comments
Closed

files inside an ignored sub-directory are not matched #19

spMohanty opened this issue Mar 18, 2018 · 5 comments

Comments

@spMohanty
Copy link

Consider the case of a directory structure like :

.
|-- directoryD
|   |-- fileE
|   `-- fileF
|-- directoryG
|   |-- directoryH
|   |   |-- fileI
|   |   |-- fileJ
|   |   |-- fileK
|   |   |-- fileL
|   |   |-- fileM
|   |   `-- fileN
|   `-- fileO
|-- fileA
|-- fileB
|-- fileC
`-- .gitignore

The contents of the .gitignore file are :

fileB
directoryD/*
directoryG/*

Now if we use pathspec to match all the files with the specs defined in .gitignore then here are the responses of match_file(filepath) function:

|-- directoryD : False
|   |-- fileE : True
|   `-- fileF : True
|-- directoryG : False
|   `-- directoryH : True
|       |-- fileI : False
|       |-- fileJ : False
|       |-- fileK : False
|       |-- fileL : False
|       |-- fileM : False
|       `-- fileN : False
|   `-- fileO : True
|-- fileA : False
|-- fileB : True
|-- fileC : True
`-- .gitignore

If you compare it with the behaviour of .gitignore inside a git repository, the files inside directoryH should all return True as a reponse to the match_file function. Or am I getting something wrong ?

@cpburnz
Copy link
Owner

cpburnz commented Apr 5, 2018

You're right, there is a discrepancy in the behavior. directoryG/* should match everything beneath directoryG which should include the files under directoryH.

@cpburnz
Copy link
Owner

cpburnz commented May 17, 2018

UPDATE: My evaluation in this comment was completely wrong and confused the issue.


I have not forgotten about this issue but I haven't had time to fix it yet.

I suspect the discrepancy is that a .gitignore does additional filtering beyond that of Git's wildmatch algorithm. If I fixed this in my implementation of wildmatch, it could unexpectedly change the results of anyone already using this for a purpose other than emulating .gitingore.

The core issue is that blacklisting files from an excluded directory is not currently implemented:

An optional prefix "!" which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent directory of that file is excluded.

See: PATTERN FORMAT bullet 4.

@bukowa
Copy link

bukowa commented Feb 9, 2021

Hey is there any workaround?

@sausag3
Copy link

sausag3 commented Dec 8, 2021

While I understand the dilemma above with breaking existing projects, as time goes on more projects are probably using this and probably a good number expect this to match the behavior Git has when trying to exactly match something as a .gitignore file. I've spent a few days on and off scratching my head trying to work out why files weren't being excluded properly (using Git itself as an interactive test to see what matching worked), only to find this open issue.

@cpburnz
Copy link
Owner

cpburnz commented Aug 23, 2022

This is now fixed and will be available in v0.10.0 when it is released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants