matches_gitignore: directory-only patterns in nested .gitignore not excluded under --exclude-gitignore
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start in mypy/modulefinder.py at matches_gitignore and compare its path handling with the sibling matches_exclude. Run the described --exclude-gitignore reproduction using a nested .gitignore containing sub/ and a real subdirectory. Done when the directory-only pattern excludes sub/ and files beneath it, matching git’s behavior.
Written by the indexing model from the issue text.
Description
Bug
matches_gitignore (mypy/modulefinder.py) fails to exclude a directory matched by a directory-only pattern (e.g. build/, node_modules/) when the pattern lives in a nested .gitignore (one in a scanned subdirectory), under --exclude-gitignore.
The trailing-slash decision uses the gitignore-relative path with a cwd-relative stat:
relative_path = os.path.relpath(subpath, gi_path)
if fscache.isdir(relative_path): # relative_path is relative to gi_path, but isdir resolves from cwd
relative_path = relative_path + "/"
When gi_path != cwd, relative_path doesn't resolve on disk, so isdir returns False, the / is never appended, and the directory-only pattern doesn't match — mypy then type-checks files the user intended to exclude.
The sibling matches_exclude in the same file does it correctly: it builds the match string with os.path.relpath(subpath) but calls fscache.isdir(subpath) on the original path.
To Reproduce
With --exclude-gitignore, a package dir containing a nested .gitignore whose content is sub/, where sub/ is a real subdirectory: mypy still checks files under sub/.
Expected Behavior
sub/ is excluded, matching git's own behavior for directory-only patterns.
Fix
Stat the original subpath (keep relative_path only for the spec match) — proposed in #21752.
- Dominant language
- Python
- Stars
- 20.6k
- Forks
- 3.3k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 56
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from python/mypy
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
bug topic-configuration topic-error-reporting
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
bug topic-attrs
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100