Why does ignore crate behaviors differently by walking and matching paths individually?

[matx64]

Hey, I'm using the ignore crate to match paths "on the fly" by working directly with a Gitignore instance instead of the Walk iterator.
From my perspective, matching paths individually should yield the same results as using the Walk iterator, but that doesn’t seem to be the case.
Here’s a simple test example:

Filesystem structure:

ignore-test-fs/
├── .gitignore
└── target/
    └── file.txt

.gitignore content

/target

tests

#[cfg(test)]
mod tests {
    use ignore::{Walk, gitignore::Gitignore};

    #[test]
    fn ignore_by_walking() {
        assert_eq!(Walk::new("./ignore-test-fs").count(), 1);
    }

    #[test]
    fn ignore_by_matching() {
        let (gi, _) = Gitignore::new("./ignore-test-fs/.gitignore");

        assert!(gi.matched("./ignore-test-fs/target", true).is_ignore());
        assert!(
            gi.matched("./ignore-test-fs/target/file.txt", false)
                .is_ignore()
        );
    }
}

output:

running 2 tests
test application::ignore::tests::ignore_by_walking ... ok
test application::ignore::tests::ignore_by_matching ... FAILED

The target directory is correctly ignored but entries inside it aren't.

If I edit the .gitignore file to the example below, all tests pass correctly:

/target
/target/*

I started a discussion because I understand this crate was specifically created for ripgrep and I'm using it out of context, but is this intended behavior for the Gitignore matcher or a bug? The crate version is 0.4.23.
Thank you!

[BurntSushi]

In the future, please provide a more straight-forward MRE. And in particular, you don't include output that shows how your test failed. Just that it did. For example:

$ mkdir -p /tmp/ripgrep-d3128/ignore-test-fs/target
$ cd /tmp/ripgrep-d3128
$ echo '/target' > ignore-test-fs/.gitignore
$ touch ignore-test-fs/target/file.txt

And then:

$ cat Cargo.toml
[package]
publish = false
name = "ripgrep-d3128"
version = "0.1.0"
edition = "2024"

[lib]
path = "lib.rs"

[dependencies]
anyhow = "1.0.99"
ignore = "0.4.23"

[profile.release]
debug = true

$ cat lib.rs
#[cfg(test)]
mod tests {
    use ignore::{gitignore::Gitignore, Walk};

    #[test]
    fn ignore_by_walking() {
        assert_eq!(Walk::new("./ignore-test-fs").count(), 1);
    }

    #[test]
    fn ignore_by_matching() {
        let (gi, _) = Gitignore::new("./ignore-test-fs/.gitignore");

        assert!(gi.matched("./ignore-test-fs/target", true).is_ignore());
        assert!(gi
            .matched("./ignore-test-fs/target/file.txt", false)
            .is_ignore());
    }
}

And then finally:

$ cargo t
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.01s
     Running unittests lib.rs (target/debug/deps/ripgrep_d3128-b41811243a23f668)

running 2 tests
test tests::ignore_by_matching ... FAILED
test tests::ignore_by_walking ... FAILED

failures:

---- tests::ignore_by_matching stdout ----

thread 'tests::ignore_by_matching' (1638210) panicked at lib.rs:15:9:
assertion failed: gi.matched("./ignore-test-fs/target/file.txt", false).is_ignore()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- tests::ignore_by_walking stdout ----

thread 'tests::ignore_by_walking' (1638211) panicked at lib.rs:7:9:
assertion `left == right` failed
  left: 3
 right: 1


failures:
    tests::ignore_by_matching
    tests::ignore_by_walking

test result: FAILED. 0 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

That's what an MRE looks like. It provides complete information as to how the test has been set up and executed. And it shows the output that I see, which lets you compare it against what you see. The goal of an MRE is to eliminate as much guesswork as possible.

Notice, for example, that both tests fail for me. That's because my example is outside of a git repository, and .gitignore files are only respected inside git repositories by default. That means you were likely running your test within a git repository. I don't know yet whether that's relevant, but I'll modify my program to match the results of yours:

#[cfg(test)]
mod tests {
    use ignore::{gitignore::Gitignore, WalkBuilder};

    #[test]
    fn ignore_by_walking() {
        assert_eq!(
            WalkBuilder::new("./ignore-test-fs")
                .require_git(false)
                .build()
                .count(),
            1
        );
    }

    #[test]
    fn ignore_by_matching() {
        let (gi, _) = Gitignore::new("./ignore-test-fs/.gitignore");

        assert!(gi.matched("./ignore-test-fs/target", true).is_ignore());
        assert!(gi
            .matched("./ignore-test-fs/target/file.txt", false)
            .is_ignore());
    }
}

Now I get:

$ cargo t
   Compiling ripgrep-d3128 v0.1.0 (/tmp/ripgrep-d3128)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.15s
     Running unittests lib.rs (target/debug/deps/ripgrep_d3128-b41811243a23f668)

running 2 tests
test tests::ignore_by_matching ... FAILED
test tests::ignore_by_walking ... ok

failures:

---- tests::ignore_by_matching stdout ----

thread 'tests::ignore_by_matching' (1638462) panicked at lib.rs:21:9:
assertion failed: gi.matched("./ignore-test-fs/target/file.txt", false).is_ignore()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::ignore_by_matching

test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

error: test failed, to rerun pass `--lib`

Now that I can actually see the test failure, the problem is much more obvious to me: the walker is ignoring ./ignore-test-fs/target and avoiding ever needing to descend into that directory. And in particular, the /target glob simply does not match target/file.txt. This is expected and correct.

The Gitignore matcher is a low level component. Using it correctly is non-trivial.

[matx64]

Thank you for the detailed reply, I will keep this behavior in mind going forward with my implementation.
And sorry for the lackluster MRE, I'll improve next time!