feat(pi-fff): search explicitly specified ignored paths via a scoped auxiliary index

Open
  • Is something wrong?
#714 10 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
65/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
search

Research direction

Start by tracing the existing AuxFinderPool path for paths outside the workspace and the path handling used by fffind and ffgrep. Add coverage for ignored directories, ignored files, normal files, both tools, and unchanged behavior for searches without an explicit path; done means explicit existing ignored paths are searchable without changing the default workspace index.

Written by the indexing model from the issue text.

Description

feature-request triaged

Summary

fffind and ffgrep currently cannot search a Git-ignored file or directory when it is explicitly supplied through the path parameter and remains inside the current workspace.

This is consistent with FFF's current indexing design: ignored paths are omitted during the initial scan, and path narrows the existing index rather than reading from disk. However, it is inconvenient for agent workflows that need to inspect a specifically named dependency, generated file, local configuration, or build artifact.

This is a pi-fff-specific feature proposal, narrower than a general --no-ignore mode.

Example

Given:

node_modules/

and a real file at:

project/node_modules/example-package/package.json

an explicit search such as:

fffind(path="node_modules/example-package/", pattern="package.json")
ffgrep(path="node_modules/example-package/package.json", pattern="some-key")

currently returns no result when the main workspace index was used.

Proposed behavior

When the caller explicitly supplies a concrete existing path:

  • For a directory, create a scoped auxiliary finder rooted at that directory.
  • For a file, create a scoped auxiliary finder rooted at its parent directory and constrain the query to that file.
  • Search that scoped finder, allowing the explicitly requested path to be discovered even if it was ignored by the parent workspace scan.
  • Keep the current ignore-aware behavior for searches without an explicit path.
  • Keep the scoped finder short-lived or bounded by the existing auxiliary-finder cache; do not index all ignored files eagerly.

The implementation could generalize the existing AuxFinderPool path used for paths outside the workspace. The internal lookup should require the requested root to match exactly rather than reusing a broader finder that may already have excluded the target subtree.

No change to the default workspace index is proposed, and this should not require a core FFF --no-ignore mode.

Acceptance criteria

  • Normal fffind / ffgrep calls without path behave exactly as they do today.
  • An explicitly specified ignored directory can be searched by both tools.
  • An explicitly specified ignored file can be searched by both tools.
  • Existing tracked paths continue to work.
  • Broad globs and nonexistent paths retain their current behavior unless deliberately included in a later change.
  • Tests cover Git-ignored directories, Git-ignored files, normal files, and both tools.

Why this is useful

Agents often need to inspect files that are intentionally not part of the project index, including installed packages under node_modules, generated outputs, local configuration, and temporary tool results. Requiring a separate shell fallback makes the tool behavior inconsistent and loses FFF's normal path/search interface.

Related discussions:

  • #108 — Does it support --no-ignore args?
  • #406 — feat: option to search git ignored files
  • #412 — Feature: Allow grep/glob outside search index
  • #530 — API to control what is ignored and --no-ignore ability to index everything

This proposal is intentionally narrower: explicit path selection acts as the opt-in, while ordinary searches remain ignore-aware.

Dominant language
Rust
Stars
11.2k
Forks
477
Avg merge
2d 8h
Merged PRs (30d)
31

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dmtrKovalenko/fff

All issues in dmtrKovalenko/fff

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.