Clone destination layout is hardcoded; users want different conventions #75

New issue

Open

opened 2026-05-23 20:55:31 +00:00 by coilysiren · 0 comments

coilysiren commented

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

Owner

Originally filed by @coilysiren on 2026-04-28T19:46:13Z - https://github.com/coilysiren/repo-recall/issues/26

Current behavior

POST /api/clone runs:

Command::new(\"gh\")
    .arg(\"repo\").arg(\"clone\").arg(&full_name)
    .current_dir(&cwd)

(src/routes/actions.rs, the clone_active handler — also the comment in src/routes/actions.rs: \"runs gh repo clone <full_name> into the scan cwd\".)

gh repo clone owner/name defaults to ./name — so the resulting layout is:

<scan_cwd>/<repo>

i.e. flat, no org grouping. For my install with REPO_RECALL_CWD=~/projects, clicking the button on coilysiren/repo-recall would produce ~/projects/repo-recall.

Why this is awkward

That flat layout doesn't match how a lot of people organize repos on disk. A non-exhaustive list of conventions in the wild:

Flat by repo name (current behavior) — ~/projects/<repo>. Fine until you have two repos with the same name from different orgs.
Grouped by org — ~/projects/<org>/<repo> (e.g. ~/projects/coilysiren/repo-recall). What I want — disambiguates same-named repos and matches gh's own repo listing structure. The Homebrew formula caveats hint this is the maintainer's layout too (REPO_RECALL_CWD=\"~/projects/coilysiren\" — i.e. one level under ~/projects is the org).
GOPATH-style by host+org — ~/src/github.com/<org>/<repo>. Common with Go devs and anyone who clones from multiple forges.
Workspace-per-repo — separate top-level directory per repo, sometimes with a sibling notes/scratch directory.
Custom per-org rules — e.g. work repos under ~/work/<repo>, personal under ~/personal/<repo>, OSS contributions under ~/oss/<org>/<repo>.

The current endpoint commits to convention #1 and gives the user no way to express any of the others. For a tool whose explicit value prop is "I already know how you organize your repos" (it walks cwd to find them), forcing a single layout for the inverse direction (clone) is asymmetric.

What I'd want

Configurable destination strategy. Rough sketches, in increasing order of complexity:

Env var with templated path, e.g. REPO_RECALL_CLONE_DEST=\"{cwd}/{owner}/{repo}\" (default \"{cwd}/{repo}\" to preserve current behavior). Trivial to implement, covers conventions 1–3 directly.
Per-org overrides, layered on top of #1 — e.g. REPO_RECALL_CLONE_DEST_coilysiren=\"~/oss/coilysiren/{repo}\". Covers convention #5.
Detect from existing layout — if any already-discovered repo from the same org sits at <cwd>/<org>/..., clone the new one alongside it. Best UX (matches the user's existing structure with no config) but adds ambiguity when the org has zero or one prior repos. Would need a fallback to one of the templated options.

Strategy #1 alone is probably enough for a first cut. The button copy could reflect the resolved path so the user sees Clone to ~/projects/coilysiren/repo-recall before clicking, and isn't surprised when it lands somewhere they didn't expect.

Adjacent: surface the destination in the UI

Independent of which strategy is picked, the dashboard's clone button currently doesn't tell the user where the repo will land. For something that touches their disk, a hover tooltip or inline → <path> would prevent the "oh, it cloned there?" surprise.

🤖 Generated with Claude Code (auto mode)

_Originally filed by @coilysiren on 2026-04-28T19:46:13Z - [https://github.com/coilysiren/repo-recall/issues/26](https://github.com/coilysiren/repo-recall/issues/26)_ ## Current behavior `POST /api/clone` runs: ```rust Command::new(\"gh\") .arg(\"repo\").arg(\"clone\").arg(&full_name) .current_dir(&cwd) ``` (`src/routes/actions.rs`, the `clone_active` handler — also the comment in [src/routes/actions.rs](https://github.com/coilysiren/repo-recall/blob/main/src/routes/actions.rs): `\"runs `gh repo clone <full_name>` into the scan cwd\"`.) `gh repo clone owner/name` defaults to `./name` — so the resulting layout is: ``` <scan_cwd>/<repo> ``` i.e. flat, no org grouping. For my install with `REPO_RECALL_CWD=~/projects`, clicking the button on `coilysiren/repo-recall` would produce `~/projects/repo-recall`. ## Why this is awkward That flat layout doesn't match how a lot of people organize repos on disk. A non-exhaustive list of conventions in the wild: 1. **Flat by repo name** (current behavior) — `~/projects/<repo>`. Fine until you have two repos with the same name from different orgs. 2. **Grouped by org** — `~/projects/<org>/<repo>` (e.g. `~/projects/coilysiren/repo-recall`). What I want — disambiguates same-named repos and matches `gh`'s own repo listing structure. The Homebrew formula caveats hint this is the maintainer's layout too (`REPO_RECALL_CWD=\"~/projects/coilysiren\"` — i.e. one level under `~/projects` *is* the org). 3. **GOPATH-style by host+org** — `~/src/github.com/<org>/<repo>`. Common with Go devs and anyone who clones from multiple forges. 4. **Workspace-per-repo** — separate top-level directory per repo, sometimes with a sibling notes/scratch directory. 5. **Custom per-org rules** — e.g. work repos under `~/work/<repo>`, personal under `~/personal/<repo>`, OSS contributions under `~/oss/<org>/<repo>`. The current endpoint commits to convention #1 and gives the user no way to express any of the others. For a tool whose explicit value prop is *\"I already know how you organize your repos\"* (it walks `cwd` to find them), forcing a single layout for the inverse direction (clone) is asymmetric. ## What I'd want Configurable destination strategy. Rough sketches, in increasing order of complexity: 1. **Env var with templated path**, e.g. `REPO_RECALL_CLONE_DEST=\"{cwd}/{owner}/{repo}\"` (default `\"{cwd}/{repo}\"` to preserve current behavior). Trivial to implement, covers conventions 1–3 directly. 2. **Per-org overrides**, layered on top of #1 — e.g. `REPO_RECALL_CLONE_DEST_coilysiren=\"~/oss/coilysiren/{repo}\"`. Covers convention #5. 3. **Detect from existing layout** — if any *already-discovered* repo from the same org sits at `<cwd>/<org>/...`, clone the new one alongside it. Best UX (matches the user's existing structure with no config) but adds ambiguity when the org has zero or one prior repos. Would need a fallback to one of the templated options. Strategy #1 alone is probably enough for a first cut. The button copy could reflect the resolved path so the user sees `Clone to ~/projects/coilysiren/repo-recall` before clicking, and isn't surprised when it lands somewhere they didn't expect. ## Adjacent: surface the destination in the UI Independent of which strategy is picked, the dashboard's clone button currently doesn't tell the user *where* the repo will land. For something that touches their disk, a hover tooltip or inline `→ <path>` would prevent the \"oh, it cloned *there*?\" surprise. 🤖 Generated with [Claude Code](https://claude.com/claude-code) (auto mode)

coilysiren added the

label

2026-05-31 01:54:58 +00:00

coilysiren added

and removed

labels

2026-05-31 07:01:08 +00:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

coilyco-flight-deck/repo-recall#75

No description provided.

Rows
Columns