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

docs(skills): say how to resolve the main clone

Browse Source 
Both skills said to derive the main clone from the checkout without saying
how, and dsh-upgrade names dsh-customize as the owner of checkout discovery
— so the technique belonged there and was missing.

dsh-customize now gives it: `git rev-parse --git-common-dir` from the
checkout yields the shared git directory, whose parent is the main clone.
It also names the two ways to get this wrong — the answer is relative for a
plain clone, and paths must be compared physically, since macOS reaches
/var through a symlink to /private/var.

dsh-upgrade links to that procedure rather than restating it.

Verified against both shapes: an adopted clone outside the container, and a
curl-shaped install whose clone is at <source>/master.
This commit is contained in:
Turtle
2026-07-31 22:26:11 +08:00
parent 2c29fedaf9
commit f3ff2e6ab4
2 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
skills/dsh-upgrade/SKILL.md
View File

@@ -9,7 +9,7 @@ Prepare and validate the upgrade in a fresh staging worktree of the main clone,
## Layout
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 main clone — the one real clone holding the object store every worktree shares, and 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 wherever it already lives, so resolve it with `git rev-parse --git-common-dir` from the staging worktree instead of assuming a path. Do not assume the main clone sits on `master` or that its `origin` is authoritative upstream — an adopted clone keeps whatever branch and remotes it had, and may point at a fork. The upgrade fetches upstream separately, per step 1. 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 main clone's single `.git` object store; the main 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 main clone, 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 main clone — the one real clone holding the object store every worktree shares, and 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 wherever it already lives, so resolve it from the staging worktree by the procedure in [`dsh-customize`](../dsh-customize/SKILL.md) instead of assuming a path. Do not assume the main clone sits on `master` or that its `origin` is authoritative upstream — an adopted clone keeps whatever branch and remotes it had, and may point at a fork. The upgrade fetches upstream separately, per step 1. 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 main clone's single `.git` object store; the main 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 main clone, and create `current` and repoint PATH to `current/bin/dsh` as a one-time migration at cutover.
## Names