fix(git): scope git-workflow's trigger to ambiguity rather than to its domains

git-workflow's description enumerated the six domains it exists to route away
from, so it competed for selection with the very skills it should be handing
off to. It now triggers on the case it actually serves: an interactive request
whose domain is not yet clear.

Also clears frontmatter drift across the plugin and removes duplicated guidance
in pc-run that had diverged from its reference.
This commit is contained in:
2026-08-31 08:01:39 +00:00
parent 8680adf4c0
commit 14af50bc07
20 changed files with 66 additions and 60 deletions

View File

@@ -4,6 +4,8 @@ source_keys:
- git-scm-worktree-docs
---
# Git worktrees
## Shared vs. per-worktree state
All worktrees share one object store, one config, and most refs under `refs/`. Each worktree keeps
@@ -12,6 +14,12 @@ its own `HEAD`, index, and per-worktree metadata (`ORIG_HEAD`, `MERGE_HEAD`, `re
worktree** exists per repo — the one `git init` or `git clone` produced — and it cannot be removed
or moved. Every other worktree is a **linked worktree** created by `git worktree add`.
## Identifying a worktree
`lock`, `move`, `remove` and `repair` accept a full path, a unique basename, or a unique partial
path. An ambiguous name errors rather than picking one; `git worktree list` shows the identifiers
that are usable.
## `add` forms
```bash
@@ -85,10 +93,11 @@ git worktree unlock <path> # when reconnected
git worktree add --track -b <branch> <path> <remote>/<branch> # explicit: no guessing at all
git worktree add <path> <branch> # shortcut: needs one clear remote
```
The shortcut fires only when `<branch>` is not found locally, none of `-b`/`-B`/`--detach` were
given, and a tracking branch of that name exists in exactly one remote. When several remotes carry
the name, `checkout.defaultRemote` picks one for disambiguation purposes; with no such setting the
shortcut has no single remote to resolve against and does not apply.
**The bare-name shortcut needs exactly one remote.** It fires only when `<branch>` is not found
locally, none of `-b`/`-B`/`--detach` were given, and a tracking branch of that name exists in
exactly one remote. When several remotes carry the name, `checkout.defaultRemote` picks one for
disambiguation purposes; with no such setting the shortcut has no single remote to resolve against
and does not apply. When the remote is ambiguous or unknown, use the explicit `--track -b` form.
`--guess-remote` covers the *other* spelling — `git worktree add <path>` with no `<commit-ish>` at
all. It bases the new branch on the remote-tracking branch matching `$(basename <path>)` when