Support POSIX character classes in gitignore bracket expressions

[gaoflow]

Summary

Git's gitignore matching (wildmatch) supports POSIX bracket character classes — [[:alpha:]], [[:digit:]], [[:space:]] and the other nine — but pathspec supports none of them. The bracket handler in pathspec/patterns/gitignore/base.py passes the bracket body straight to Python's re, which does not understand POSIX classes, so it builds a broken regex (Python emits FutureWarning: Possible nested set at position 1, which is slated to become a hard re.error) and silently returns the wrong match.

The existing code comment already states the design goal — "Maintain consistency with Git because that is the expected behavior." This closes that gap for POSIX classes.

Reproduction

Oracle is git check-ignore (ground truth wildmatch):

import pathspec
spec = pathspec.PathSpec.from_lines('gitwildmatch', ['[[:digit:]]'])
spec.match_file('5')   # git ignores '5'; pathspec returns False, with a FutureWarning

Fix

Translate each of the 12 POSIX classes to the explicit ASCII range that git's wildmatch uses:

class	range		class	range
alnum	0-9A-Za-z		lower	a-z
alpha	A-Za-z		print	\x20-\x7e
blank	\t space		punct	!-/:-@\[-`{-~
cntrl	\x00-\x1f\x7f		space	\t\n\r space
digit	0-9		upper	A-Z
graph	\x21-\x7e		xdigit	0-9A-Fa-f

These are deliberately ASCII — git's wildmatch uses locale-independent is* checks on bytes — and not Python's Unicode-aware \w/\d/\s. For example [[:digit:]] matches 0–9 but not the Arabic-Indic digit ٠ (U+0660), matching git.

Two supporting changes:

• The closing-bracket scan now skips over [:name:] tokens, so the class's internal ] is no longer mistaken for the end of the whole bracket expression (that truncation is what produced the broken regex before).
• An unknown or negated class name ([[:bogus:]], [[:^alpha:]]) is treated as a malformed pattern that matches nothing, which is what git does (verified against git check-ignore).

Classes compose with other bracket members, ranges and bracket negation as git allows: [[:digit:]a-f_], [![:digit:]], [[:alpha:]0-9], [[:upper:][:digit:]].

Conformance

I built a differential harness against real git check-ignore (git 2.50.1) covering, for each of the 12 classes, every testable byte 0x01–0xFF, plus negated/unknown names, composition, and the ASCII boundary. Before this change: 466 byte-level divergences from git; after: 0.

Tests

New tests in test_04_gitignore_spec.py cover the exact regex translation for all 12 classes, per-class match behaviour, composition, the ASCII-only boundary (non-ASCII digits/letters must not match), and discarding of unknown/negated class names. Full suite passes on the re and re2 backends (156 passed, 46 skipped for the uninstalled hyperscan backend).

Scope

This is limited to POSIX character classes. Backslash escaping inside a bracket (e.g. [\]] to match a literal ]) is a separate pre-existing gap and is intentionally not touched here.

[cpburnz]

Thanks for the pull request. Can you show that git/gitignore actually supports POSIX character classes? I see no reference in the gitignore docs.

[gaoflow]

The docs reference it indirectly: gitignore(5) says bracket ranges follow fnmatch(3) with the FNM_PATHNAME flag, and POSIX fnmatch defines the [:alpha:] style classes. Empirically git honors them — with .gitignore = [[:digit:]]*.txt, git check-ignore 1.txt matches and a.txt does not (tested on git 2.50). Git also bundles its own compat/fnmatch with POSIX-class support for platforms whose libc lacks it, so this is not platform-dependent. The PR deliberately maps each class to git's ASCII, locale-independent character set rather than Python's Unicode-aware \w/\d.

[cpburnz]

The implementation and tests all look good. I've confirmed git does indeed use POSIX classes which I didn't expect. Thanks!