git-worktrees 0.4.1__tar.gz → 0.4.2__tar.gz

git_worktrees-0.4.2/.claude/settings.json

@@ -0,0 +1,6 @@
+{
+  "enabledPlugins": {
+    "release-notes@release-tools": true,
+    "release@release-tools": true
+  }
+}

{git_worktrees-0.4.1 → git_worktrees-0.4.2}/.github/workflows/publish.yml

@@ -144,8 +144,7 @@ jobs:
         uses: astral-sh/setup-uv@ae62891fec2bb8e7d6c99fc78c9fec3a63790f8d # v10.0.0
         with:
           python-version: "3.14"
-          enable-cache: true
-          cache-suffix: ${{ github.workflow }}-${{ github.job }}
+          enable-cache: false
 
       - name: Download distributions
         uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8
@@ -179,8 +178,7 @@ jobs:
         uses: astral-sh/setup-uv@ae62891fec2bb8e7d6c99fc78c9fec3a63790f8d # v10.0.0
         with:
           python-version: "3.14"
-          enable-cache: true
-          cache-suffix: ${{ github.workflow }}-${{ github.job }}
+          enable-cache: false
 
       - name: Verify it installs from PyPI
         run: scripts/verify-publish.bash --prod

git_worktrees-0.4.2/.releasetools.yaml

@@ -0,0 +1,23 @@
+# How this repository releases, read by every releasetools tool.
+#
+# Conventions: https://github.com/releasetools/conventions
+#
+# One project: the distribution is `git-worktrees`, which is not the name of
+# this repository and not the package anything imports. PyPI already holds a
+# `worktrees` belonging to somebody else, so the registry URL names the
+# distribution rather than either of the others.
+projects:
+  - path: ./
+    manifest: pyproject.toml
+    changelog: CHANGELOG.md
+    bump: uv version {version}
+
+release:
+  branch: main
+  # GitHub replays the author's commits unsigned on a rebase merge, and the
+  # `main` ruleset requires signed commits and linear history, so a squash is
+  # the only one it takes. It is signed by GitHub's web-flow key.
+  merge: squash
+  checks: tests.yml
+  publish: publish.yml
+  registry: https://pypi.org/pypi/git-worktrees/{version}/json

{git_worktrees-0.4.1 → git_worktrees-0.4.2}/CHANGELOG.md

@@ -17,6 +17,10 @@ not in here, whatever it cost to build.
 A release closes with a `### Choices` section when a decision in it is worth
 the reader's time: what was chosen, and what the alternative failed to do.
 
+## 0.4.2 - 2026-09-22
+
+CLI behavior is unchanged from 0.4.1.
+
 ## 0.4.1 - 2026-09-21
 
 CLI behavior is unchanged from 0.4.0.

{git_worktrees-0.4.1 → git_worktrees-0.4.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: git-worktrees
-Version: 0.4.1
+Version: 0.4.2
 Summary: Git worktree commands that refuse to lose work.
 Project-URL: Bug reports, https://github.com/MihaiBojin/worktrees/issues/new
 Project-URL: Source, https://github.com/MihaiBojin/worktrees

{git_worktrees-0.4.1 → git_worktrees-0.4.2}/docs/DEVELOPMENT.md

@@ -152,36 +152,50 @@ network. `GIT_CONFIG_GLOBAL` carries that: without it git still reads
 ## Publishing a version
 
 ```console
-/release 0.2.0
+/release:cut 0.2.0
 ```
 
-The skill at `.agents/skills/release/` does the whole of it: cut
-`release/v0.2.0` from `origin/main`, `uv version 0.2.0`, open the pull
-request, wait for its checks, merge with `--rebase`, wait for main's own run
-on the rebased commit, and only then tag. The tag lands on a commit already
-proved green, so it never has to move.
+That does the whole of it: cut `release/v0.2.0` from `origin/main`,
+`uv version 0.2.0`, open the pull request, wait for its checks, squash-merge,
+wait for main's own run on the merged commit, and only then tag. The tag lands
+on a commit already proved green, so it never has to move.
+
+What each step needs is in `.releasetools.yaml`: the branch, the squash, the
+workflow that has to be green, the workflow the tag starts, the URL that must
+not already carry the version, and the command that sets it. The keys are the
+[releasetools conventions](https://github.com/releasetools/conventions/blob/main/FORMAT.md),
+so the guards and the release read the same file.
+
+The squash is not a preference. The `main` ruleset requires signed commits and
+linear history: GitHub replays the author's commits unsigned on a rebase merge
+and refuses with `Base branch requires signed commits`, and a merge commit is
+not linear. A squash is one commit, signed by GitHub's web-flow key, and its
+subject becomes `Release 0.2.0 (#NN)`.
 
 `rt release::prechecks` runs first and refuses a version that is not `x.y.z`,
 a dirty tree, a tag that already exists on the remote, a version that is not
 after the newest release tag, a commit that is not on main, and a version PyPI
 already carries. That last one matters most: PyPI rejects a duplicate at the
-very end of a publish run, after everything else has already happened.
+very end of a publish run, after everything else has already happened. The
+distribution is `git-worktrees`; PyPI's `worktrees` belongs to somebody else.
 
 `/release-notes:prepare` writes the `CHANGELOG.md` entry on the release branch,
-so the notes are reviewed in the same pull request as the version bump. It
-comes from the release-tools marketplace:
+so the notes are reviewed in the same pull request as the version bump. Both
+commands come from the release-tools marketplace:
 
 ```console
 claude plugin marketplace add releasetools/agent-plugins --scope project
+claude plugin install release@release-tools --scope project
 claude plugin install release-notes@release-tools --scope project
 ```
 
-`--scope project` declares it in this repository rather than in your own
-configuration, so the next person to release is offered the same plugin.
+`--scope project` declares them in this repository rather than in your own
+configuration, so the next person to release is offered the same plugins.
+`rt` has to be v0.4.0 or newer, which is where `version::bump` arrived.
 
-`publish.yml` reads that section back out for the GitHub release, and `build`
-refuses a tag whose version has no section, before anything is published.
-Nothing is generated from pull request titles.
+`publish.yml` reads that changelog section back out for the GitHub release,
+and `build` refuses a tag whose version has no section, before anything is
+published. Nothing is generated from pull request titles.
 
 By hand it is the same four commands:
 

{git_worktrees-0.4.1 → git_worktrees-0.4.2}/pyproject.toml

@@ -9,7 +9,7 @@ authors = [
 ]
 # Static, and the single source of truth for the version. Bump it in a pull
 # request and run `uv lock`; the release tag only has to agree with it.
-version = "0.4.1"
+version = "0.4.2"
 # The standard library answers every question this asks. A dependency here
 # would be paid on every invocation, and an invocation is 67 ms of which 25 ms
 # is the interpreter starting.

{git_worktrees-0.4.1 → git_worktrees-0.4.2}/uv.lock

@@ -40,7 +40,7 @@ wheels = [
 
 [[package]]
 name = "git-worktrees"
-version = "0.4.1"
+version = "0.4.2"
 source = { editable = "." }
 
 [package.optional-dependencies]

git_worktrees-0.4.1/.agents/skills/release/SKILL.md

@@ -1,138 +0,0 @@
----
-name: release
-description: Release a version of this package to PyPI. Bumps the version on a release branch, opens and merges the pull request once its checks pass, then tags the merged commit so publish.yml uploads it. Use when the user says "release", "cut a release", "ship x.y.z", or "/release x.y.z".
-user-invocable: true
-allowed-tools: Bash(git:*), Bash(gh:*), Bash(uv:*), Bash(rt:*), Bash(scripts/*.bash:*)
----
-
-# release
-
-Release `$ARGUMENTS` of this package. The argument is the version, with or
-without a leading `v`; strip it and use the bare `x.y.z` everywhere below.
-
-With no argument, ask which version. Do not guess one from the commits.
-
-Every step is one command. Run them in order, read what each says before
-running the next, and stop at the first failure rather than working around
-it. Nothing here is worth improvising: a release that goes wrong is on PyPI
-forever.
-
-## 1. Everything that has to be true first
-
-```bash
-git fetch --all --prune
-rt release::prechecks <version> \
-    --branch main \
-    --check-registry-url "https://pypi.org/pypi/$(uv version | cut -d' ' -f1)/<version>/json"
-```
-
-That checks the shape of the version, a clean working tree, that the tag is
-free on the remote, that the version is after the newest release tag, that
-HEAD is on main, and that PyPI does not already carry it. If it refuses, say
-what it said and stop. Do not fix a dirty tree by stashing on the user's
-behalf.
-
-`rt` is `releasetools/cli`, installed with `brew install releasetools/tap/releasetools-cli`
-or the installer in its README. Every check it runs refuses when it cannot
-prove what it was asked to prove, so a doubtful answer stops the release
-rather than passing it.
-
-## 2. The branch, the notes, and the bump
-
-```bash
-git switch --create release/v<version> --no-track origin/main
-```
-
-Then run `/release-notes:prepare <version>`, from the ReleaseTools plugin. It
-rules on every commit since the previous tag, writes the body to
-`.git/RELEASE_EDITMSG`, and puts the entry in `CHANGELOG.md` under
-`## <version> - <date>`. It shows the draft and waits before its last step,
-so the user changes it there.
-
-Do not write that entry by hand and do not skip it: `publish.yml` reads the
-section back out for the GitHub release, and `build` refuses a tag whose
-version has no section.
-
-```bash
-uv version <version>
-git commit --all --message "Release <version>"
-git push --set-upstream origin refs/heads/release/v<version>
-```
-
-`uv version` rewrites `pyproject.toml` and re-locks, so the commit carries
-those two files and `CHANGELOG.md`. Check that with `git show --stat`
-before pushing: a commit
-missing `uv.lock` fails `uv sync --locked` in CI, and it fails after the
-merge rather than before it.
-
-Branch from `origin/main` rather than from `main`, so a stale local copy
-cannot become the release.
-
-## 3. The pull request, and its checks
-
-```bash
-gh pr create --base main --title "Release <version>" --body "..."
-gh pr checks --watch --fail-fast
-```
-
-The body is the changelog entry just written. It is already the summary,
-already reviewed by the reader, and writing a second one invites the two to
-disagree.
-
-`--watch` blocks. When it reports a failure, report which check failed and
-its URL, and stop. The branch and the pull request stay; nothing has been
-tagged and nothing published.
-
-## 4. Merge, then wait for main
-
-```bash
-gh pr merge --squash --delete-branch
-git switch main && git pull --ff-only
-rt github::await_workflow "$(git rev-parse HEAD)" tests.yml
-```
-
-`--squash`, because the `main` ruleset requires signed commits and linear
-history: GitHub cannot sign the commits a rebase merge writes and refuses it
-with `Base branch requires signed commits`, and a merge commit is off. A
-squash is signed by GitHub's web-flow key, which is expected here and not
-something to route around. The subject becomes `Release <version> (#NN)`.
-
-The wait matters. A squash onto a main that moved is a tree neither the
-branch nor main has tested, and the tag must only ever land on a commit
-already proved green. `github::await_workflow` blocks until `tests.yml` finishes
-on that commit and exits non-zero if it failed.
-
-If it failed: `main` now carries the version bump and no release exists. Say
-so plainly. The fix is another pull request, and then this skill again at the
-same version, since no tag was created.
-
-## 5. Tag, which is what publishes
-
-```bash
-git tag --annotate v<version> --message "v<version>"
-git push origin refs/tags/v<version>
-gh run watch "$(gh run list --workflow publish.yml --limit 1 --json databaseId --jq '.[0].databaseId')" --exit-status
-```
-
-Pushing the tag is the release. `publish.yml` re-checks the tag against
-`pyproject.toml`, that the commit is on `main`, and the tests, then builds
-once, installs the wheel it built and uploads it to PyPI. There is no
-TestPyPI upload here; `testpypi.yml` published this commit when the merge put
-it on `main`.
-
-`release` needs that upload alone, so the GitHub release appears while
-`verify` is still installing from PyPI. A red `verify` under a green
-`publish` means the index has not caught up, not that the version is
-missing.
-
-Report the PyPI URL and the GitHub release URL when it finishes.
-
-## What this never does
-
-Move a tag. A tag names one commit forever; a version that needs a second
-attempt gets the next number. If `publish.yml` fails *after* the PyPI upload,
-in `verify` or `release`, re-run it with
-`gh workflow run publish.yml --ref v<version>` rather than re-tagging.
-
-Delete a release branch that has not merged, stash the user's work, force
-anything, or retry a failed check by re-running it in the hope it passes.

git_worktrees-0.4.1/.claude/settings.json

@@ -1,5 +0,0 @@
-{
-  "enabledPlugins": {
-    "release-notes@release-tools": true
-  }
-}