[canac]

Add a remote_repo variable that returns the repo name from the remote URL. Unlike repo, it stays consistent even if the clone was renamed.

Feel free to reject, or suggest other names for the variable. But this change would improve my workflow. I hope you don't mind my submitting a PR before opening an issue. Thanks for an amazing developer tool!

AI Disclosure 🤖: I used Claude Code to generate the changes, but reviewed every line and made adjustments.

[worktrunk-bot]

Both sites that populate owner — build_hook_context and UserConfig::format_path — are updated, so the changelog's "available everywhere owner is" holds; GitRemoteUrl::repo() already strips .git in split_namespace_repo, and REPO_VARS, the help table, and the generated doc mirrors all move together.

On the name you asked about: remote_repo reads well beside the existing remote and remote_url, and the prefix is what disambiguates it from repo (the directory on disk), so I'd keep it. Worth an explicit call from @max-sixty before it ships, though — template variable names are part of the config surface, so renaming after a release is a break.

[max-sixty]

@canac thanks, very reasonable!

@worktrunk-bot please resolve conflicts

[max-sixty]

@worktrunk-bot please de-slop

[worktrunk-bot]

De-slopped in 62b11b2 — 131 words down to 47.

What went: the worked git clone … work example, the enumeration of every scope the variable reaches (hook and alias bodies, --execute, wt step eval, worktree-path), the .git-stripping mechanic, and the {% if remote_repo %} guard. The release skill puts a non-headline bullet at 40 words or under and says to leave the "why it works this way" detail in the PR description, which is where all of that now lives.

What stayed: the contrast with repo that motivates the variable, and the unset-without-a-remote caveat, since that one changes how a template gets written.

- **`remote_repo` names the repository as the remote spells it**: `repo` is the directory on disk, so a renamed clone reports the new name. `{{ remote_repo }}` takes it from the primary remote's URL, available everywhere `owner` is and unset when no remote parses. ([#3745](https://github.com/max-sixty/worktrunk/pull/3745), thanks @canac)

Also added the PR link and the thanks @canac credit — the release skill asks for both on an external contribution, and every 0.72.0 bullet carries them.

[worktrunk-bot]

Conflicts resolved in 9009e1c (merge of main), and the changelog entry de-slopped in 62b11b2 — reply on that thread has the before/after.

Only CHANGELOG.md conflicted: 0.72.0 shipped while this branch was open, so the release consumed the ## Unreleased heading this entry was written under. Kept both — a fresh ## Unreleased holding the remote_repo bullet, above the released 0.72.0 section. Everything else merged clean, including src/cli/mod.rs and the help snapshots.

The snapshots were the thing worth checking, since main moved the help surface a fair amount in the meantime (schema v2, --print-schema, the color refactor in #3777). test_docs_are_in_sync and the 47 test_help* cases pass unchanged, so no regeneration was needed.

All required checks are green on 62b11b2's predecessor and re-running now, including codecov/patch. The only non-terminal check on the merge commit was affected tests (macos, advisory), which is advisory.

Verification

Run locally against the merge commit before pushing:

cargo build --tests                                          ok
cargo test --lib --bins                        1482 + 965 + 11 + 1 passed
cargo test --test integration test_docs_are_in_sync          ok
cargo test --test integration test_help                      47 passed
cargo test --test integration eval                           12 passed
cargo test --test integration -- step_alias user_hooks post_start_commands   238 passed

CI on the merge commit 9009e1c: test (linux), test (macos), test (windows), lint, fast-checks, check-docs, gate, review, codecov/patch, codecov/project all pass.