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

git_worktrees-0.4.3/.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.3}/.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.3/.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.3}/AGENTS.md

@@ -300,10 +300,10 @@ regions. `git merge-tree` reports a conflict, and a diff cannot tell that
 from real work left over. There is no content probe that answers this.
 
 So the forge answers it, asked last because it costs a round trip and only
-where git already failed. A merged request is cross-checked against
-`unpushed_count`: it speaks for what reached it, never for commits nobody
-pushed, and no upstream at all stays `unknown` rather than becoming zero.
-`--no-forge` keeps a run offline.
+where git already failed. A merged request with a configured upstream that
+Git reports as `[gone]` permits pruning, subject to the worktree protections.
+When the upstream exists, `unpushed_count` checks for local commits it lacks.
+No upstream configured stays `unknown`. `--no-forge` keeps a run offline.
 
 ## Three verdicts, and the third is not a softer second
 

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

@@ -17,6 +17,18 @@ 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.3 - 2026-09-22
+
+### Fixed
+
+`gwp` can prune a branch whose pull request is merged and whose configured
+upstream is gone. Branches with no upstream configured remain unknown.
+Forge-confirmed branches with ignored files require `--delete-ignored`.
+
+## 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.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: git-worktrees
-Version: 0.4.1
+Version: 0.4.3
 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
@@ -223,10 +223,12 @@ Where git cannot tell, the forge is asked. A branch merged as part of a
 stack is that case: its changes reach the head branch across several
 squashes, so the intermediate state it holds differs from the final one in
 the same regions, and a diff cannot separate a stale branch from one with
-work left. A merged pull request settles it, cross-checked against the
-commits an upstream has not got, because a request speaks for what reached
-it and nothing about what never did. `--no-forge` decides from git alone, and
-so does a run whose fetch just failed.
+work left. A merged pull request with a configured upstream that is gone
+makes the branch eligible for pruning. When the upstream still exists,
+unpushed commits keep the branch. A branch with no upstream configured
+stays `unknown`. Worktree protections still apply, including the check for
+ignored files. `--no-forge` decides from git alone, and so does a run whose
+fetch just failed.
 
 The question goes to the repository the command is standing in and nowhere
 else. `GH_REPO` and `GITLAB_REPO` beat that directory, so both are dropped

{git_worktrees-0.4.1 → git_worktrees-0.4.3}/README.md

@@ -197,10 +197,12 @@ Where git cannot tell, the forge is asked. A branch merged as part of a
 stack is that case: its changes reach the head branch across several
 squashes, so the intermediate state it holds differs from the final one in
 the same regions, and a diff cannot separate a stale branch from one with
-work left. A merged pull request settles it, cross-checked against the
-commits an upstream has not got, because a request speaks for what reached
-it and nothing about what never did. `--no-forge` decides from git alone, and
-so does a run whose fetch just failed.
+work left. A merged pull request with a configured upstream that is gone
+makes the branch eligible for pruning. When the upstream still exists,
+unpushed commits keep the branch. A branch with no upstream configured
+stays `unknown`. Worktree protections still apply, including the check for
+ignored files. `--no-forge` decides from git alone, and so does a run whose
+fetch just failed.
 
 The question goes to the repository the command is standing in and nowhere
 else. `GH_REPO` and `GITLAB_REPO` beat that directory, so both are dropped

{git_worktrees-0.4.1 → git_worktrees-0.4.3}/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.3}/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.3"
 # 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.3}/src/worktrees/forge.py

@@ -6,9 +6,9 @@ state it holds differs from the final one in the same regions, so a stale
 branch whose work is upstream and a branch with real work left look exactly
 alike to a diff.
 
-The forge knows. It is asked last, because it costs a round trip and because
-it can be wrong about work pushed after the merge, which is why the answer is
-cross-checked against the commits an upstream has not got.
+The forge is asked after the content checks. An existing upstream is checked
+for unpushed commits. A merged request with a missing configured upstream
+permits pruning, subject to the worktree protections.
 """
 
 from __future__ import annotations

{git_worktrees-0.4.1 → git_worktrees-0.4.3}/src/worktrees/repo.py

@@ -59,6 +59,11 @@ def upstream_of(branch: str) -> None:
     """The upstream a branch tracks. Failure means unknown, not none."""
 
 
+@git("for-each-ref --format=%(upstream:track) refs/heads/$branch")
+def upstream_tracking(branch: str) -> None:
+    """Tracking status, including [gone] for a missing configured upstream."""
+
+
 @git("rev-list --count $a..$b", ok=(0, 128))
 def count_between(a: str, b: str) -> None:
     """How many commits b has that a does not."""

{git_worktrees-0.4.1 → git_worktrees-0.4.3}/src/worktrees/verdicts.py

@@ -185,11 +185,9 @@ def _forge_reason(
     Returns (reason, verdict), or ("", "") when the forge said nothing and
     the content probes keep the answer.
 
-    A merged request speaks for what was pushed. Commits an upstream has not
-    got were never in it, and a branch with no upstream at all leaves that
-    unknown rather than zero: branches made here do not track, so "no
-    upstream" is the normal state for exactly the ones this would otherwise
-    reap.
+    A merged request with a missing configured upstream permits pruning.
+    An existing upstream is checked for unpushed commits. A branch with no
+    tracking configuration stays unknown.
     """
     request = forge.request_for(branch, repo=repo)
     if request is None or request.state not in ("MERGED", "CLOSED"):
@@ -198,6 +196,18 @@ def _forge_reason(
     lower = request.state.lower()
     unpushed = R.unpushed_count(branch, repo=repo)
     if unpushed is None:
+        if R.upstream_tracking(branch, repo=repo).out.strip() == "[gone]":
+            if request.state == "MERGED":
+                return (
+                    f"its {request.noun} #{request.number} is merged "
+                    "and its upstream is gone",
+                    "",
+                )
+            return (
+                f"its {request.noun} is {lower}, but its upstream is gone; "
+                "cannot check for unpushed commits",
+                UNKNOWN,
+            )
         return (
             f"its {request.noun} is {lower}, but the branch has no upstream "
             "to have been pushed to",
@@ -209,4 +219,4 @@ def _forge_reason(
             "are not in it",
             KEEP,
         )
-    return f"its {request.noun} #{request.number} is {lower}", REMOVE
+    return f"its {request.noun} #{request.number} is {lower}", ""

{git_worktrees-0.4.1 → git_worktrees-0.4.3}/tests/test_forge.py

@@ -94,6 +94,22 @@ def test_a_merged_request_cannot_speak_for_unpushed_commits(world, with_forge) -
     assert "1 commit(s) here are not in it" in row.why
 
 
+@pytest.mark.parametrize("delete_ignored", [False, True])
+def test_a_merged_request_with_an_existing_upstream_checks_ignored_files(
+    world, with_forge, delete_ignored
+):
+    with_forge([{"number": 12, "state": "MERGED"}])
+    wt = world.worktree("stacked")
+    world.commit(".gitignore", "cache\n", at=wt)
+    _push(world, "stacked", wt)
+    (wt / "cache").write_text("keep\n")
+    rows = verdicts.assess(
+        R.worktrees(), "", "refs/heads/main", "main", delete_ignored, ask_forge=True
+    )
+    row = next(v for v in rows if v.branch == "stacked")
+    assert row.verdict == (verdicts.REMOVE if delete_ignored else verdicts.KEEP)
+
+
 def test_no_upstream_is_unknown_rather_than_zero(world, with_forge) -> None:
     """Branches made here do not track, so this is the normal state for
     exactly the ones a merged request would otherwise reap."""
@@ -109,6 +125,88 @@ def test_no_upstream_is_unknown_rather_than_zero(world, with_forge) -> None:
     assert "no upstream" in row.why
 
 
+@pytest.fixture
+def gone_upstream(world):
+    wt = world.worktree("stacked")
+    sha = world.commit("s.txt", "s\n", at=wt)
+    _push(world, "stacked", wt)
+    world.git(
+        "update-ref", "-d", "refs/heads/stacked", sha, at=world.root / "stacked.git"
+    )
+    world.git("fetch", "--prune", "origin")
+    assert world.git("config", "--get", "branch.stacked.merge") == "refs/heads/stacked"
+    assert not R.upstream_of("stacked")
+    assert R.unpushed_count("stacked") is None
+    return wt
+
+
+@pytest.mark.parametrize("state", ["MERGED", "CLOSED", "OPEN", None])
+def test_a_gone_upstream_requires_a_merged_request(
+    world, with_forge, gone_upstream, state
+):
+    with_forge([{"number": 12, "state": state}] if state else [])
+    rows = verdicts.assess(
+        R.worktrees(), "", "refs/heads/main", "main", False, ask_forge=True
+    )
+    row = next(v for v in rows if v.branch == "stacked")
+    assert row.verdict == (verdicts.REMOVE if state == "MERGED" else verdicts.UNKNOWN)
+    if state == "MERGED":
+        assert row.why == "its pull request #12 is merged and its upstream is gone"
+    elif state == "CLOSED":
+        assert "upstream is gone" in row.why
+
+
+@pytest.mark.parametrize("protection", ["dirty", "ignored", "locked", "current"])
+def test_a_merged_request_with_a_gone_upstream_keeps_worktree_protections(
+    world, with_forge, gone_upstream, protection
+):
+    with_forge([{"number": 12, "state": "MERGED"}])
+    if protection == "dirty":
+        (gone_upstream / "s.txt").write_text("unfinished\n")
+    elif protection == "ignored":
+        world.git("config", "core.excludesFile", str(world.root / "ignore"))
+        (world.root / "ignore").write_text("cache\n")
+        (gone_upstream / "cache").write_text("keep\n")
+    elif protection == "locked":
+        world.git("worktree", "lock", str(gone_upstream))
+    rows = verdicts.assess(
+        R.worktrees(),
+        "",
+        "refs/heads/main",
+        "main",
+        False,
+        here=str(gone_upstream) if protection == "current" else "",
+        ask_forge=True,
+    )
+    row = next(v for v in rows if v.branch == "stacked")
+    assert row.verdict == verdicts.KEEP
+
+
+def test_prune_removes_a_merged_branch_with_a_gone_upstream(
+    world, with_forge, gone_upstream
+):
+    bin_dir = with_forge([{"number": 12, "state": "MERGED"}])
+    env = env_for(world)
+    env["PATH"] = f"{bin_dir}{os.pathsep}{env['PATH']}"
+    proc = subprocess.run(
+        [
+            sys.executable,
+            "-c",
+            "from worktrees.cli import gwp; raise SystemExit(gwp())",
+            "--no-fetch",
+            "--yes",
+        ],
+        cwd=str(world.repo),
+        capture_output=True,
+        text=True,
+        env=env,
+    )
+    assert proc.returncode == 0, proc.stderr
+    assert not gone_upstream.exists()
+    assert not R.ref_exists("refs/heads/stacked")
+    assert world.repo.exists()
+
+
 def test_an_open_request_decides_nothing(world, with_forge) -> None:
     with_forge([{"number": 12, "state": "OPEN"}])
     wt = world.worktree("live")

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

@@ -40,7 +40,7 @@ wheels = [
 
 [[package]]
 name = "git-worktrees"
-version = "0.4.1"
+version = "0.4.3"
 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
-  }
-}