From 269360a4eaebabae065699d33bde18acfb135ddc Mon Sep 17 00:00:00 2001 From: NotExpectedYet Date: Sat, 26 Sep 2026 06:51:49 +0100 Subject: [PATCH] docs: lead the install instructions with the published git spec MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `dsh plugin --profile web add /path/to/dsh-recall` was the only form given, which is the development one: it is what you type against a checkout, not what somebody installing this repository types. The published spec now comes first, exactly as the maintainer writes it, with the `#semver:^0.1.0` variant beside it because that is what keeps `dsh plugin update` following release tags — the Releases section explains why, and this points at it. The directory form stays, reframed as the alternative it is: a `link:` dependency that tracks a working tree, so an edit needs no reinstall. The directory form is the one exercised in a profile here; the remote form cannot be resolved from this machine, which has no credentials for that host. --- README.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/README.md b/README.md index 122d2b4..f9cc7c0 100644 --- a/README.md +++ b/README.md @@ -49,6 +49,22 @@ about a millisecond; the only per-query network cost is one embedding call. ## Install +```sh +dsh plugin --profile web add git+https://git.notexpectedyet.com/Not-Expected-Yet/dsh-recall.git +``` + +That form installs whatever the default branch holds, pinned to a commit in the +profile's lockfile. The semver fragment installs the newest release tag instead, +and is what makes `dsh plugin update` follow releases — see +[Releases](#releases) for the tag and versioning rules: + +```sh +dsh plugin --profile web add 'git+https://git.notexpectedyet.com/Not-Expected-Yet/dsh-recall.git#semver:^0.1.0' +``` + +To run your own copy instead, add the directory — that becomes a `link:` +dependency which tracks the working tree, so an edit needs no reinstall: + ```sh dsh plugin --profile web add /path/to/dsh-recall ```