Pine/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases 1 Wiki Activity

docs(skills): the master clone may live outside the container

Browse Source 
Adoption installs the master wherever the adopted clone already is, so
dsh-upgrade and dsh-customize can no longer state <source>/master as fact.

Both skills already derive the master from the launcher, so the procedures
hold; only the layout description was wrong. dsh-upgrade now names
`git rev-parse --git-common-dir` as the way to resolve it.

The legacy-migration clauses stay: installs made before this change can
still link PATH straight at a worktree.
This commit is contained in:
Turtle
2026-07-31 22:14:32 +08:00
parent f3a1ff41b7
commit adb88ad36d
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
skills/dsh-upgrade/SKILL.md
+1 -1
View File
@@ -9,7 +9,7 @@ Prepare and validate the upgrade in a fresh staging worktree of the master clone
## Layout
A source-installed DSH keeps every checkout under one container directory `<source>` (default `~/.dsh/source`): the master clone at `<source>/master` (remote tracking `master`, the fetch/upgrade base, never a launcher target) and each staging checkout as a git worktree `<source>/staging-<timestamp>` on branch `dsh-staging/<timestamp>`. The stable symlink `<source>/current` points at the active staging worktree, and the PATH launcher links to `<source>/current/bin/dsh`, so the launcher resolves PATH -> `current` -> staging worktree. Cutover repoints `current` alone; the PATH launcher is written once at install and never moves. All worktrees share the master clone's single `.git` object store; the master clone's `.git/info/exclude` is inherited by every linked worktree, so one `.agents/merge.lock` entry there excludes the lock in all of them. An older install may link PATH straight at a worktree (no `current`) or use scattered sibling clones; if so, follow the recorded launcher checkout rather than assuming this layout, treat that sibling clone as its own master, and create `current` and repoint PATH to `current/bin/dsh` as a one-time migration at cutover.
A source-installed DSH keeps its staging checkouts and `current` under one container directory `<source>` (default `~/.dsh/source`): each staging checkout is a git worktree `<source>/staging-<timestamp>` on branch `dsh-staging/<timestamp>`. The master clone — remote tracking `master`, the fetch/upgrade base, never a launcher target — is at `<source>/master` for a `curl` install, but the container owns worktrees rather than the repository: installing from an existing clone adopts that clone as the master wherever it already lives, so resolve it with `git rev-parse --git-common-dir` from the staging worktree instead of assuming a path. The stable symlink `<source>/current` points at the active staging worktree, and the PATH launcher links to `<source>/current/bin/dsh`, so the launcher resolves PATH -> `current` -> staging worktree. Cutover repoints `current` alone; the PATH launcher is written once at install and never moves. All worktrees share the master clone's single `.git` object store; the master clone's `.git/info/exclude` is inherited by every linked worktree, so one `.agents/merge.lock` entry there excludes the lock in all of them. An older install may link PATH straight at a worktree (no `current`) or use scattered sibling clones; if so, follow the recorded launcher checkout rather than assuming this layout, treat that sibling clone as its own master, and create `current` and repoint PATH to `current/bin/dsh` as a one-time migration at cutover.
## Names