Hi, I ran into a case through Hawkeye where checking whether a directory is ignored can be misleading if tracked files exist below that directory.

Context:

• Downstream issue: https://github.com/korandoru/hawkeye/blob/c57037afedf940370c41eb660837c8aa928d472a/fmt/src/git.rs#L243-L247
• OpenDAL PR that worked around it: chore: Update .gitignore to remove bin and build entries apache/opendal#7460
• Related PR that exposed the problem: chore(license): add licensing comments to stub_gen.rs apache/opendal#7426

In OpenDAL, bindings/python/.gitignore had a rule like:

bin/

At the same time, there is a checked-in file under a matching directory:

!/src/bin/stub_gen.rs

Hawkeye uses gitoxide to process dirty working tree entries. For a DirectoryContents item, it recursively walks the directory and calls:

let platform = excludes.at_path(rela_path, mode)?;
if file_type.is_dir() && platform.is_excluded() {
    it.skip_current_dir();
    continue;
}

The problem is that src/bin/ is reported as excluded by the ignore rule, so Hawkeye skips the whole directory. However, the directory can still contain tracked files, or files that are otherwise intentionally included/force-added. In that case, treating the directory as simply ignored causes tools to miss files that are actually part of the repository.

A minimal reproduction would be:

git init
mkdir -p src/bin
printf 'bin/\n' > .gitignore
printf 'fn main() {}\n' > src/bin/stub_gen.rs
git add -f src/bin/stub_gen.rs .gitignore
git commit -m init

From a tool author's perspective, when excludes.at_path("src/bin", DIR).is_excluded() returns true, it is not enough to decide that the whole subtree can be skipped, because the index may still contain tracked files below that directory.

Could you clarify the recommended way to handle this with gitoxide?

In particular:

1. Should callers always consult the index before skipping an ignored directory?
2. Is there an API that can tell whether an ignored directory may contain tracked entries or re-included entries below it?
3. Should status / exclude handling expose more detailed information for this case, instead of only reporting that the directory path itself is ignored?

For Hawkeye, the desired behavior is either:

• do not report/handle such a path as simply ignored if tracked files exist below it; or
• provide enough information to say "this directory is ignored, but it may contain files that are not ignored / are tracked, so callers should descend or query the index."

Thanks!