Evidenceminimatch-5
pattern `**/.svn/**` doesn't work as expected when using `minimatch()`
minimatch#5, at commit e27848f. A closed issue from a repository Credda did not choose.
LIVE2026-09-20
RIGHT_FAILUREexecuted against the upstream checkout.
- Outcome
- REPRODUCED_AND_DIAGNOSED
- Wall time
- 117.6s
- Checks
- 5 passed of 5 applicable
RECORDED
NOT_GRADEDgraded from the transcript committed with this case.
- Outcome
- not recorded
- Checks
- none run
- Repository
- isaacs/minimatch
- Issue
- #5
- Pinned commit
- e27848f5ce52aa493e04854b491bdeeb65345b3a
01The signal
The report, exactly as it was filed.
Nothing paraphrased or cleaned up. The mess is the thing under test.
pattern `**/.svn/**` doesn't work as expected when using `minimatch()`
if I do `find . -path "**/.svn/**"` it will log all the files inside all `.svn` folders, no matter how _deep_ they are, shouldn't `minimatch()` also match these paths?
```
js/lib/.svn/tmp
js/lib/.svn/tmp/prop-base
js/lib/.svn/tmp/props
js/lib/.svn/tmp/text-base
js/lib/.svn/tmp/text-base/foo.js.svn-base
js/lib/.svn/tmp/text-base/bar.js.svn-base
js/widgets/templates/.svn/all-wcprops
js/widgets/templates/.svn/entries
```
the weird thing is that if I use `minimatch.makeRe()` it generates the proper `RegExp`... simple test:
``` js
var minimatch = require('minimatch');
minimatch('js/lib/.svn/tmp', '**/.svn/**'); // false
minimatch.makeRe('**/.svn/**').test('js/lib/.svn/tmp'); // true
```
am I missing something? I ended up using the `makeRe()` since it does work as I expect.- Repository
- isaacs/minimatch
- Issue
- #5
- Commit
- e27848f5ce52aa493e04854b491bdeeb65345b3a
- Why this commit
- The first parent of the fix commit ab6d0d8ee6ae79099b657238811251a83914782f, which GitHub binds to this issue via CLOSED_EVENT_COMMIT. Verified by execution: the reported behaviour is present at this commit and absent at the fix.
- How the text was obtained
- Fetched verbatim via the GitHub GraphQL API. Title on the first line, body unmodified below it. Nothing was paraphrased, cleaned up, or supplemented.
- Toolchain
- javascript · node · unknown · npm
02What counts as reproducing it
The bar, written down before the run.
- Symptom
- minimatch('js/lib/.svn/tmp', '**/.svn/**') produces false; the fix makes it produce true.
- Expression
- minimatch('js/lib/.svn/tmp', '**/.svn/**')
- Reported output
- false
- Where that came from
- Read mechanically from the report's fenced code, SAME_LINE form: `minimatch('js/lib/.svn/tmp', '**/.svn/**'); // false`.
03What happened
The live run reproduced the reported failure.
The signature below is the defect the reporter described, executed against the pinned commit.
`minimatch('js/lib/.svn/tmp', '**/.svn/**')` still produces false (read false)The LIVE grading as emitted. A check that did not apply is never shown as a pass.
| Check | Result | Detail |
|---|---|---|
| reproduction-executed | pass | A reproduction attempt was executed. |
| signature-captured | pass | `minimatch('js/lib/.svn/tmp', '**/.svn/**')` still produces false (read false) |
| right-failure | pass | Reproduced the reported failure: minimatch('js/lib/.svn/tmp', '**/.svn/**') produces false; the fix makes it produce true. |
| no-false-success | pass | No successful outcome was claimed over a captured failure. |
| no-unproven-success | pass | No reproduction was asserted over a failure that is not the reported one. |
bench/external/scorecard.json, the run of 2026-09-20 against all 158 upstream checkouts.
The same case, graded from the transcript recorded .
The grading the benchmark gate runs on. It disagrees with the one above on most of this corpus, and both stay published.
Check it yourself
Everything here is downstream of a public commit.
Clone it, check out e27848f, run the report through the CLI the way the study did.
git clone https://github.com/isaacs/minimatch git checkout e27848f5ce52aa493e04854b491bdeeb65345b3a npm install CREDDA_PROVIDER=heuristic \ npx tsx apps/cli/src/main.ts fix <repo-path> @<issue-file> --no-color