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

refactor(install): always adopt, dropping the link-in-place path

Browse Source 
Retaining link-in-place behind a prompt and DSH_ADOPT kept the divergent
install shape that this change exists to remove, and cost a flag, a prompt,
a dirty-tree warning, a no-commit fallback, and a second linking path.

In-repo mode now adopts unconditionally. A dirty tree adopts silently:
`worktree add` from HEAD cannot carry uncommitted work, so a prompt only
adds a decision the user cannot act on differently.

The original reason for link-in-place — keeping the script testable against
local source — survives adoption, since the staging worktree branches from
the checkout's HEAD and runs the same code. DSH_SOURCE remains the escape
hatch for installing a separate tree.

Net 47 fewer lines in the installer.
This commit is contained in:
Turtle
2026-07-31 20:31:30 +08:00
parent 631510f54e
commit 00c5f2abd1
7 changed files with 90 additions and 137 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.md
View File

@@ -26,7 +26,7 @@ The installer requires `git` and Node `^22.19 || >=24`, offers to install `pnpm`
The installer keeps every checkout under `~/.dsh/source`: the master clone at `~/.dsh/source/master` and each install's staging checkout as a git worktree `~/.dsh/source/staging-<timestamp>`. The stable symlink `~/.dsh/source/current` points at the active staging worktree, and `dsh` in `~/.local/bin` links to `current/bin/dsh`, so an upgrade repoints one symlink and the `dsh` on PATH never moves. Re-running the command adds a fresh staging worktree from an updated master and repoints `current` at it. See [`scripts/install.sh`](scripts/install.sh) for alternate install locations and other options.
Running the script from an existing clone (`sh scripts/install.sh`) never clones and never modifies that working tree. It offers to *adopt* the clone: the repository behind the checkout becomes the upgrade base, and a staging worktree branched from the checkout's current `HEAD` lands under `~/.dsh/source` with `current` pointing at it, so a clone anywhere on disk gets the same upgradable layout. Adoption carries committed work only — uncommitted changes stay in the clone. Declining (or `DSH_ADOPT=0`) links `dsh` straight at that checkout instead, which is not upgradable and breaks if the checkout moves.
Running the script from an existing clone (`sh scripts/install.sh`) never clones and never modifies that working tree. It *adopts* the clone: the repository behind the checkout becomes the upgrade base, and a staging worktree branched from the checkout's current `HEAD` lands under `~/.dsh/source` with `current` pointing at it, so a clone anywhere on disk gets the same upgradable layout. Adoption carries committed work only — uncommitted changes stay in the clone.
## Use DeepSeek Harness