Filter repos to a user's dayjob (e.g. by GitHub org membership) #68

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-29T20:23:00Z - https://github.com/coilysiren/repo-recall/issues/37

Problem

When REPO_RECALL_CWD points at a parent directory that holds repos from multiple contexts — dayjob work, side projects, personal stuff — the dashboard mixes them all together. For someone who lives mostly in their work repos during the day, the personal repos are noise; for someone winding down on a side project at night, the work repos are noise.

Today the only way to scope this is to point REPO_RECALL_CWD at a single subdirectory (e.g. /Users/me/projects/acme rather than /Users/me/projects). That works but is coarse — it requires re-pointing the launch agent and reloading every time you context-switch, and it assumes you've physically organized your repos by org on disk, which not everyone does.

Proposal

Let repo-recall filter the dashboard to a "context," with at least these options:

By GitHub org membership. Detect each repo's remote_url org/owner; group repos by org. Offer a filter dropdown (or URL param like ?org=acme) that limits the dashboard to repos owned by a given org.
Automatic dayjob detection. As a heuristic: if the user is a member of a GitHub org and a parent folder name on disk matches that org's name (e.g. ~/projects/acme/... for org acme), treat that as the user's "dayjob context" and offer a one-click toggle to scope to it. This makes the common case zero-config.
Manual override. Let the user pin a context (org name or folder path) in config so the filter persists across reloads.

Why folder-name heuristic

The parent-folder-name → org-name match is a strong signal in practice — engineers who clone many repos for one employer almost always nest them under a folder named after the org. Combined with gh api user/orgs (or equivalent) to confirm the user is actually a member, false positives are rare.

Out of scope (for this issue)

Multi-org dayjobs (someone working across two employer orgs simultaneously). Probably handled later by allowing multiple pinned contexts.
Non-GitHub remotes (GitLab, Bitbucket). Same mechanism would work but would need separate auth wiring.

_Originally filed by @coilysiren on 2026-04-29T20:23:00Z - [https://github.com/coilysiren/repo-recall/issues/37](https://github.com/coilysiren/repo-recall/issues/37)_ ## Problem When `REPO_RECALL_CWD` points at a parent directory that holds repos from multiple contexts — dayjob work, side projects, personal stuff — the dashboard mixes them all together. For someone who lives mostly in their work repos during the day, the personal repos are noise; for someone winding down on a side project at night, the work repos are noise. Today the only way to scope this is to point `REPO_RECALL_CWD` at a single subdirectory (e.g. `/Users/me/projects/acme` rather than `/Users/me/projects`). That works but is coarse — it requires re-pointing the launch agent and reloading every time you context-switch, and it assumes you've physically organized your repos by org on disk, which not everyone does. ## Proposal Let repo-recall filter the dashboard to a "context," with at least these options: 1. **By GitHub org membership.** Detect each repo's `remote_url` org/owner; group repos by org. Offer a filter dropdown (or URL param like `?org=acme`) that limits the dashboard to repos owned by a given org. 2. **Automatic dayjob detection.** As a heuristic: if the user is a member of a GitHub org *and* a parent folder name on disk matches that org's name (e.g. `~/projects/acme/...` for org `acme`), treat that as the user's "dayjob context" and offer a one-click toggle to scope to it. This makes the common case zero-config. 3. **Manual override.** Let the user pin a context (org name or folder path) in config so the filter persists across reloads. ## Why folder-name heuristic The parent-folder-name → org-name match is a strong signal in practice — engineers who clone many repos for one employer almost always nest them under a folder named after the org. Combined with `gh api user/orgs` (or equivalent) to confirm the user is actually a member, false positives are rare. ## Out of scope (for this issue) - Multi-org dayjobs (someone working across two employer orgs simultaneously). Probably handled later by allowing multiple pinned contexts. - Non-GitHub remotes (GitLab, Bitbucket). Same mechanism would work but would need separate auth wiring.

coilysiren commented

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

Author

Owner

Iceboxed in the 2026-05-29 backlog burn-down: Dayjob org-membership filter, speculative multi-user scope. Reopen anytime if it becomes real.

coilysiren

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