confusing interplay between dot-ignore and fs_grep_files options.suppress

Open
#1,044 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Domain
cli, developer-experience

Research direction

Start with .jp/mcp/tools/fs/grep_files.toml and compare its options.suppress entries with the project's .ignore rules and issue #626. The issue does not define a specific implementation or documentation outcome; progress would require deciding how the dot-ignore and suppress behavior should be explained or changed.

Written by the indexing model from the issue text.

Description

From .jp/mcp/tools/fs/grep_files.toml

# Disclosure blocks like `.git/` belong on every tool that returns contents, so
# keep those in step. `**/target/` is a flood block and lives only on the tools
# that enumerate in bulk; `fs_read_file` omits it deliberately, so an exact build
# log stays retrievable (issue #626).
options.suppress = [".git/", "**/target/"]

Ignoring the technobabble offense here, one of my project's .ignore files unignores some things under target/:

[...]

# un-ignore desired trees
!**/target/doc/
!**/target/doc/**
!**/target/log/
!**/target/log/**
!/target/payload-review/
!/target/payload-review/**
!/target/CLAUDE*

I think the fs_grep_files design is suggesting that since the tool can find target/doc/ by the LLM directly naming that path, nothing is irretrievably ignored. It's just suppressed from nonspecific searches. So even though I have a complex .ignore, the upstream options.suppress is still right for me.

I agree that all these concerns are different:

  • read concerns;
  • write concerns;
  • context concerns; and
  • staging concerns.

And it's even different programs reading the current separate files. Yet it still feels like wizard-or-well-visualized configuration needs to focus on this more for devs to be able to understand their project's settings.

I kind of feel like this issue is a journal entry of realizing the design, and I should delete it. Ugh, I will leave it up for a day to collect comments.

Dominant language
Rust
Stars
16
Forks
3
Avg merge
1d 1h
Merged PRs (30d)
121

Contributor guide

No contributing guide indexed for this repository

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 dcdpr/jp

All issues in dcdpr/jp

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.