Filter "active on GitHub, not cloned" by recency (default ~90d, configurable) #74

New issue

Closed

opened 2026-05-23 20:55:30 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-05-23 20:55:30 +00:00

Owner

Originally filed by @coilysiren on 2026-04-28T19:47:20Z - https://github.com/coilysiren/repo-recall/issues/27

Current behavior

fetch_active_repos (src/commits.rs) calls:

gh repo list --limit 100 --json nameWithOwner,url,sshUrl,defaultBranchRef,pushedAt,description,isFork,isArchived

gh repo list defaults to ordering by most-recent push but applies no time filter — so a user with more than 100 lifetime repos gets a 100-row mix dominated by recent activity, but for users with fewer repos the list trails off into long-abandoned ones (old hackathon projects, archived experiments, forks they made years ago to read source). Those then show up on the dashboard as "active on GitHub, not cloned" — which is misleading: they're visible to gh, not active.

The schema already pulls pushedAt (active_remote_repos.pushed_at in src/db.rs), so the data needed for a recency filter is on hand — it's just not used to filter anything.

What I'd want

Treat "active" as pushed in the last N days, not exists in gh repo list. Default to 90 days (a quarter — long enough to catch a repo I cloned for one task, archived locally, and want to come back to; short enough to not surface ten-year-old forks).

Configurable via env var, e.g. REPO_RECALL_ACTIVE_REPOS_DAYS=90. Setting it to 0 could disable the filter (current behavior, for users who want everything).

Where the filter goes

Two reasonable spots:

At insert time — drop stale rows in ingest_active_repos (src/routes/refresh.rs) before they hit the active_remote_repos table. Keeps the table small and the rest of the codebase oblivious to the cutoff.
At query time — filter in get_active_repo_by_full_name and whatever populates the dashboard panel. Lets the user change REPO_RECALL_ACTIVE_REPOS_DAYS and have it take effect on the next page load instead of the next refresh.

Option 2 is probably nicer (matches the README's promise that "the schema is wiped and rebuilt on every process start" — startup tuning shouldn't have to wait a full scan cycle to feel different).

Adjacent: also exclude archived / fork-only

isFork and isArchived are already in the schema but I don't see them used as filter inputs either. Probably worth a separate decision per flag:

isArchived: true → exclude by default (archived repos are explicitly not active).
isFork: true → keep visible by default (forks can be active workspaces), maybe with a UI tag so the user knows it's a fork.

Could also be env vars (REPO_RECALL_INCLUDE_ARCHIVED=false, REPO_RECALL_INCLUDE_FORKS=true) if there's appetite, but archived-exclusion is probably the right default with no opt-out needed.

🤖 Generated with Claude Code (auto mode)

_Originally filed by @coilysiren on 2026-04-28T19:47:20Z - [https://github.com/coilysiren/repo-recall/issues/27](https://github.com/coilysiren/repo-recall/issues/27)_ ## Current behavior `fetch_active_repos` (`src/commits.rs`) calls: ```sh gh repo list --limit 100 --json nameWithOwner,url,sshUrl,defaultBranchRef,pushedAt,description,isFork,isArchived ``` `gh repo list` defaults to ordering by most-recent push but applies **no time filter** — so a user with more than 100 lifetime repos gets a 100-row mix dominated by recent activity, but for users with fewer repos the list trails off into long-abandoned ones (old hackathon projects, archived experiments, forks they made years ago to read source). Those then show up on the dashboard as \"active on GitHub, not cloned\" — which is misleading: they're *visible to gh*, not *active*. The schema already pulls `pushedAt` (`active_remote_repos.pushed_at` in `src/db.rs`), so the data needed for a recency filter is on hand — it's just not used to filter anything. ## What I'd want Treat \"active\" as *pushed in the last N days*, not *exists in `gh repo list`*. Default to 90 days (a quarter — long enough to catch a repo I cloned for one task, archived locally, and want to come back to; short enough to not surface ten-year-old forks). Configurable via env var, e.g. `REPO_RECALL_ACTIVE_REPOS_DAYS=90`. Setting it to `0` could disable the filter (current behavior, for users who want everything). ## Where the filter goes Two reasonable spots: 1. **At insert time** — drop stale rows in `ingest_active_repos` (`src/routes/refresh.rs`) before they hit the `active_remote_repos` table. Keeps the table small and the rest of the codebase oblivious to the cutoff. 2. **At query time** — filter in `get_active_repo_by_full_name` and whatever populates the dashboard panel. Lets the user change `REPO_RECALL_ACTIVE_REPOS_DAYS` and have it take effect on the next page load instead of the next refresh. Option 2 is probably nicer (matches the README's promise that \"the schema is wiped and rebuilt on every process start\" — startup tuning shouldn't have to wait a full scan cycle to feel different). ## Adjacent: also exclude archived / fork-only `isFork` and `isArchived` are already in the schema but I don't see them used as filter inputs either. Probably worth a separate decision per flag: - `isArchived: true` → exclude by default (archived repos are explicitly *not* active). - `isFork: true` → keep visible by default (forks can be active workspaces), maybe with a UI tag so the user knows it's a fork. Could also be env vars (`REPO_RECALL_INCLUDE_ARCHIVED=false`, `REPO_RECALL_INCLUDE_FORKS=true`) if there's appetite, but archived-exclusion is probably the right default with no opt-out needed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) (auto mode)

coilysiren commented

2026-05-30 05:43:51 +00:00

Author

Owner

Iceboxed in the 2026-05-29 backlog burn-down: Recency filter, speculative refinement of unbuilt feature. Reopen anytime if it becomes real.

coilysiren

2026-05-30 05:43:52 +00:00