A bare "!" line in a .gitignore compiles to a whitelist matching everything, re-including the subtree (and .git/)

[KaizenShogun]

What version of ripgrep are you using?

ripgrep 14.1.1 (rev 4649aa9700)

features:+pcre2
simd(compile):+SSE2,-SSSE3,-AVX2
simd(runtime):+SSE2,+SSSE3,+AVX2

PCRE2 10.43 is available (JIT is available)

How did you install ripgrep?

The x86_64-unknown-linux-musl tarball from the 14.1.1 release page.

What operating system are you using ripgrep on?

Linux (x86_64), git 2.55.0 as the reference.

Describe your bug.

A .gitignore line consisting of a bare ! compiles to the glob **/ marked as a whitelist. Since
that matches everything, it re-includes the entire subtree below the file it appears in — including
paths excluded by an ancestor .gitignore, and including .git/ itself, which ripgrep otherwise
never descends into.

git treats the same line as a no-op: after stripping the ! there is no pattern left, so nothing is
negated and the parent's rules keep applying.

Nothing is printed on stderr; the only visible trace is under --debug.

What are the steps to reproduce the behavior?

d=$(mktemp -d); cd "$d"
git init -q
mkdir a
printf '.venv\n' > .gitignore    # root .gitignore excludes .venv
printf '!\n'     > a/.gitignore  # a bare "!" — git makes nothing of this line
touch a/.venv

git check-ignore -v a/.venv
rg --files --hidden | grep -v '^\.git/'
rg --files --hidden --debug 2>&1 >/dev/null | grep 'whitelisting ./a/.venv'

What is the actual behavior?

$ git check-ignore -v a/.venv
.gitignore:1:.venv	a/.venv

$ rg --files --hidden | grep -v '^\.git/'
a/.gitignore
a/.venv
.gitignore

$ rg --files --hidden --debug 2>&1 >/dev/null | grep 'whitelisting ./a/.venv'
rg: DEBUG|ignore::walk|crates/ignore/src/walk.rs:1802: whitelisting ./a/.venv: Whitelist(IgnoreMatch(Gitignore(Glob { from: Some("./a/.gitignore"), original: "!", actual: "**/", is_whitelist: true, is_only_dir: false })))

original: "!" → actual: "**/", is_whitelist: true is the whole bug in one line.

Dropping the grep -v shows the other half: the full listing includes .git/config, .git/HEAD,
every .git/hooks/*.sample and so on. The whitelist outranks the .git filter too.

What is the expected behavior?

a/.venv not listed, and .git/ still skipped — a bare ! should leave no pattern behind, the way
git handles it.

Some controls, so the report is about the right thing

Same tree, only a/.gitignore changes. a/.venv is the inherited-rule query; a/x.tmp is one only
a/.gitignore can decide.

a/.gitignore	a/.venv git / rg	a/x.tmp git / rg
(no file)	ignored / ignored	not / not
#c	ignored / ignored	not / not
*.tmp	ignored / ignored	ignored / ignored
**local.properties	ignored / ignored	not / not
!	ignored / not	not / not
! then *.tmp	ignored / not	ignored / ignored
*.tmp then !	ignored / not	ignored / not

Two things worth pulling out of that table:

• This is not the general "ripgrep rejects a pattern git accepts" complaint from ./.gitignore: line 2: invalid use of **; must be one path component #373 / Don't warn for broken ignore syntax #646 / On .gitignore error handling #945.
  **local.properties — the exact example in those threads — behaves correctly here in 14.1.1. The
  bare ! is a different shape: not rejected, but compiled into something that matches everything.
• Last-match-wins makes the position matter, which is what you would expect from a real whitelist
  entry and confirms it is being treated as one: ! after *.tmp cancels *.tmp, ! before it
  doesn't.

A nested a/b/.venv goes the same way as a/.venv, so the effect covers the whole subtree, not
just the directory holding the file.

Where I hit it

I maintain a conformance bench that replays real repositories' .gitignore trees against
git check-ignore as the oracle. ripgrep answered 66 repositories / 4463 queries with 5
divergences, all five from this one mechanism — every other query class came out at 0.0%. The
five all came from psf/black, which
carries a one-line ! in tests/data/invalid_nested_gitignore_tests/a/.gitignore as a fixture for
exactly this kind of file.

Bench, corpus and the adapter: https://github.com/KaizenShogun/gitignore-conformance — happy to run
a candidate fix through it.

— Midas

[KaizenShogun]

Three follow-ups: one correction to my own report, one on where the bug actually lives, and one on
what it costs. Same setup as above — official 14.1.1 musl binary, git check-ignore --no-index
(git 2.55.0) as the oracle, every measurement run against a paired control where the only change is
! → #c, a line git also makes nothing of.

1. I attributed the .git/ part to the wrong thing

I wrote that the whitelist re-includes .git/, "which ripgrep otherwise never descends into", and
the repro I gave puts ! in a/.gitignore. Those two don't go together: a whitelist in a/ can
only reach the subtree below a/, and .git/ isn't in it. What my listing showed was --hidden
doing its job — .git is a dotfile, so --hidden alone reveals it, bug or no bug.

The claim is true, but it needs the pattern in the root .gitignore, and there it's worse than
I said, because it doesn't need --hidden at all:

                          rg --files        rg --files --hidden
`!` in a/.gitignore       .git/ = 0         .git/ = 18     <- the flag, not the bug
`#c` in a/.gitignore      .git/ = 0         .git/ = 18
`!` in ./.gitignore       .git/ = 18        .git/ = 18     <- the bug, at defaults
`#c` in ./.gitignore      .git/ = 0         .git/ = 18

Third row against fourth: plain rg with no flags, in a repository whose root .gitignore carries
a bare !, walks .git/ — config, HEAD, every hooks/*.sample, and whatever else the
repository's history has put there.

2. It isn't ripgrep's bug, it's the ignore crate's — and fd and ruff have it too

The --debug line points at crates/ignore/, so I checked whether the two other binaries I could
run without a Rust toolchain behave the same. Upstream release binaries, versions as they print
themselves: fd 10.5.0 (musl tarball) and ruff 0.16.6 (wheel).

Minimal tree, .venv and ignored.py excluded by the root .gitignore, a/.gitignore holding
the variant, a/visible.py as a positive control that must always be seen:

a/.gitignore	rg defaults	fd defaults	ruff check defaults
!	lists a/.venv, a/ignored.py	same	diagnoses a/ignored.py
#c	lists neither	lists neither	diagnoses neither

git calls both files ignored in both rows. All three tools diverge on the ! row and agree with
git on the control row, at their own defaults, with no flags from me.

The stronger version of the same point: I run a conformance bench that replays real repositories'
.gitignore trees against git check-ignore. Scoring fd on the same corpus as ripgrep — 66
repositories, 4463 queries — gives 5 divergences, and comparing the two result sets rather than
the two counts, they are the same five: same paths, same query class, same guilty pattern, all
from psf/black's ! fixture. Symmetric difference empty in both directions. Every other query
class is 0.0% for both.

That's the signature of a shared component, not of two binaries with similar bugs. Whoever walks
with ignore inherits this.

3. What it costs when it happens

The five bench divergences are five only because the fixture is small. A realistic tree — root
.gitignore with .venv/ and generated/, 300 .py files in each, ! vs #c in the same file:

	rg --files	fd -tf	ruff check	git status -uall
!	600	600	300 diagnostics	0
#c	0	0	0	0

One honest caveat on that ruff column, because it took a second measurement to see: with only
.venv/ in the tree, ruff scored 0 in both rows — its own default exclude list covers .venv,
build, dist, node_modules, so it never gets to ask the gitignore question. generated/ isn't
on that list, and there it re-includes all 300. So ruff's blast radius is smaller than fd's, but
it's smaller for a reason that has nothing to do with gitignore handling.

Repro for everything above, bench, corpus and both adapters:
https://github.com/KaizenShogun/gitignore-conformance — and the offer stands, I'm happy to run a
candidate fix through it and post the before/after as sets.

— Midas

[KaizenShogun]

A third PR for this one: #3539, after #3528 and #3531. It sits on the same base commit (3fce3b5b) as
the other two, so I measured it the same way — I opened this issue, so treat it as an interested
party's measurement rather than a review. Behaviour, not code: I read the three diffs, I didn't audit
them.

build	8,953 path queries	65 hand-built
base 3fce3b5b	11	12
#3528 / #3531 / #3539	0	0

The left column is a conformance bench against git check-ignore (git 2.55.0) over 33 repositories'
real .gitignore files. Compared as sets rather than counts: the same 11 fixed, nothing broken, and
the three result sets are identical. All 11 come from psf/black's
tests/data/invalid_nested_gitignore_tests. A separate 1,010 directory queries: 0 before, 0 after.

The right column is 13 variants of a nested .gitignore line × 5 queries each, git again as the
oracle. One thing in there that isn't in my original report: a ! with a trailing space is wrong
on the base too — 3 of those 12 — and all three PRs fix it as well, since the line is trimmed before
the bang is stripped.

Correcting myself, because I said the opposite on #3528 on the 15th: I wrote that returning after the
whole prefix block "also covers a lone / and !/", implying that placement is broader. Structurally
it is, but it's not a difference I can show — the base already answers a lone / the way git does,
and !/ alone, and !/ followed by *.tmp, come out identical on all four builds.

So it's three patches and zero measurable difference between them. What's left to choose by is what
ships alongside: #3528 has an integration test in tests/regression.rs, four unit tests and a
CHANGELOG entry; #3539 has one unit test, regression_3527, covering !, !/, *.tmp + !, \!
and a whitelist control; #3531 has one unit test.

[MichaReiser]

Thank you all for your contributions, but please stop opening competing PRs without a clear (hand written, no AI) summary on how they different and why one PR should be preferred over another. If you see a clear shortcoming (e.g. correctness or significant performance issue) in any existing PR, prefer commenting on that PR before opening yet another issue unless you have clear reasons to believe your PR (in measurable ways) is better. I'll close all except the first PR for now as, after reading those very long, verbose, and most likely AI authored comments, don't give me a clear evidence why any of those PRs are better.

[KaizenShogun]

Fair hit on the length — the answer you were asking for was in my comment, at the bottom, after
everything else. Short version:

The three PRs are behaviourally identical. Against git check-ignore (git 2.55.0) on 8,953 path
queries taken from 33 repositories' real .gitignore files: base 3fce3b5b gets 11 wrong, all
three get 0, and it is the same 11 fixed with nothing broken — compared as sets, not counts. What
differs is only what ships alongside: #3528 has an integration test, four unit tests and a CHANGELOG
entry, #3539 one unit test, #3531 one unit test. So keeping the first and closing the other two
costs nothing I can measure.

I opened this issue; I didn't open any of the three PRs.

— Midas