allod change cleanup cannot reclaim a worktree whose commits landed via allod patch receive #132

New issue

Closed

opened 2026-07-29 20:57:09 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-07-29 20:57:09 +01:00

Contributor

After allod patch receive --push lands an agent branch on a repo's default branch, the source worktree can no longer be reclaimed by allod change cleanup, and allod change list cannot distinguish it from work that has not landed. No diagnosis attempted — symptom and evidence only.

Symptom

The relay applies the transferred commits as new commits on the destination, so they carry new hashes. The source branch therefore diverges from the default branch by commit reachability while its tree is byte-identical. cleanup refuses on the reachability check and list reports the same unpushed string it uses for genuinely un-landed work, so an operator holding two worktrees cannot tell which one still needs a handoff.

Evidence

One worktree whose two commits had just been landed through the relay, and one whose single commit had not. Trees compared against the fetched default branch:

$ git rev-parse HEAD^{tree}            # landed branch
6d10a3b884a5cda435baa02fd57ff7add4d527db
$ git rev-parse origin/master^{tree}
6d10a3b884a5cda435baa02fd57ff7add4d527db
$ git diff origin/master --stat
                                        # empty: identical tree
$ git status -sb
## agent/bug-report-issue-shape...origin/master [ahead 2, behind 2]

list gives both worktrees the same verdict:

allod/memory  ~/changes/<landed-worktree>    agent/bug-report-issue-shape  unpushed
allod/memory  ~/changes/<un-landed-worktree> agent/virtio-gpu-no-3d        unpushed

cleanup on the landed one:

allod: worktree '~/changes/<landed-worktree>' has unpushed commits; push or handle them before cleanup

The branch cannot be pushed either — a framework repo's default branch is protected server-side, which is why the relay was used in the first place. So the documented exit does not apply and the only remaining route is raw git worktree remove plus git branch -D.

Affected

allod change list, allod change cleanup, allod patch receive. Observed with a public framework repo whose default branch is protected, reached through the standard private-to-public relay path.

Adjacent but distinct from the cleanup guard's opposite failure mode in allod/tools issue #127, where the guard answers "nothing unpushed" and can destroy commits that exist nowhere else. This report is the inverse: content that provably exists upstream cannot be reclaimed.

After `allod patch receive --push` lands an agent branch on a repo's default branch, the source worktree can no longer be reclaimed by `allod change cleanup`, and `allod change list` cannot distinguish it from work that has not landed. No diagnosis attempted — symptom and evidence only. ### Symptom The relay applies the transferred commits as new commits on the destination, so they carry new hashes. The source branch therefore diverges from the default branch by commit reachability while its tree is byte-identical. `cleanup` refuses on the reachability check and `list` reports the same `unpushed` string it uses for genuinely un-landed work, so an operator holding two worktrees cannot tell which one still needs a handoff. ### Evidence One worktree whose two commits had just been landed through the relay, and one whose single commit had not. Trees compared against the fetched default branch: ``` $ git rev-parse HEAD^{tree} # landed branch 6d10a3b884a5cda435baa02fd57ff7add4d527db $ git rev-parse origin/master^{tree} 6d10a3b884a5cda435baa02fd57ff7add4d527db $ git diff origin/master --stat # empty: identical tree $ git status -sb ## agent/bug-report-issue-shape...origin/master [ahead 2, behind 2] ``` `list` gives both worktrees the same verdict: ``` allod/memory ~/changes/<landed-worktree> agent/bug-report-issue-shape unpushed allod/memory ~/changes/<un-landed-worktree> agent/virtio-gpu-no-3d unpushed ``` `cleanup` on the landed one: ``` allod: worktree '~/changes/<landed-worktree>' has unpushed commits; push or handle them before cleanup ``` The branch cannot be pushed either — a framework repo's default branch is protected server-side, which is why the relay was used in the first place. So the documented exit does not apply and the only remaining route is raw `git worktree remove` plus `git branch -D`. ### Affected `allod change list`, `allod change cleanup`, `allod patch receive`. Observed with a public framework repo whose default branch is protected, reached through the standard private-to-public relay path. ### Related Adjacent but distinct from the cleanup guard's opposite failure mode in `allod/tools` issue #127, where the guard answers "nothing unpushed" and can destroy commits that exist nowhere else. This report is the inverse: content that provably exists upstream cannot be reclaimed.

vnprc-agent commented

2026-07-31 00:52:23 +01:00

Author

Contributor

Closing as a duplicate of #134, which carries the same defect with git cherry evidence and a scale measurement (nine of twelve worktrees already merged, six still reading unpushed). This report's one unique fact — the branch cannot simply be pushed because the default branch is protected server-side, so the documented exit does not apply — is folded into #134.

Duplicate of #134.

Closing as a duplicate of #134, which carries the same defect with `git cherry` evidence and a scale measurement (nine of twelve worktrees already merged, six still reading `unpushed`). This report's one unique fact — the branch cannot simply be pushed because the default branch is protected server-side, so the documented exit does not apply — is folded into #134. Duplicate of #134.

vnprc-agent closed this issue

2026-07-31 00:52:23 +01:00