TOP PRIORITY: consolidate all open PRs onto one next branch, one PR #189

New Issue

clawbot · 2026-08-10T14:30:42+02:00

clawbot commented

2026-08-10 14:30:42 +02:00

This outranks all feature work in this repo. Do it before anything else.

Owner instruction, sneak 2026-08-10:

why are there so many PRs in one repo? there should be one and only one PR open at a time for the next milestone, as we squash commits on main and i'm tired of merge conflicts after merging one bc i don't know the order.

He squashes on merge, so N open PRs means N-1 conflict the moment the first lands. This repo has already produced exactly that: #178 was built on #169's branch and went un-mergeable the instant #169 landed.

What to do

Fold every open PR here onto a single next branch, resolving the conflicts between them yourself:

#171
#175
#178 (currently needs-rebase — it targeted #169's branch, which has since merged to main)
#185 (currently needs-rework; include it only if its rework completes, otherwise leave it out and note why)

TODO.md will conflict across most of them; #178's edit is deliberately a single insert at the top of Completed Steps to make that trivial.

Definition of done

One next branch containing the included PRs as separate issue-closing commits, each message ending (closes #N).
Exactly ONE open PR in this repo: next -> main, titled for the milestone.
make check green on the combined result, and make build still produces release artifacts with DEBUG off — the guard added by #178 must pass against the consolidated tree, not just its own branch.
Every superseded PR closed with a comment saying where its work went, and its branch deleted.
Nothing lost: confirm each original PR's commits are represented in next before closing it.

Model going forward

next is the branch for the NEXT MILESTONE, not the next release; main changes between releases as milestones land. Every worker works in its own clone, pulls next before starting, and pulls and resolves conflicts itself immediately before pushing. Exactly one open PR in this repo at all times from now on.

**This outranks all feature work in this repo. Do it before anything else.** Owner instruction, sneak 2026-08-10: > why are there so many PRs in one repo? there should be one and only one PR open at a time for the next milestone, as we squash commits on main and i'm tired of merge conflicts after merging one bc i don't know the order. He squashes on merge, so N open PRs means N-1 conflict the moment the first lands. This repo has already produced exactly that: https://git.eeqj.de/sneak/AutistMask/pulls/178 was built on #169's branch and went un-mergeable the instant #169 landed. ## What to do Fold every open PR here onto a single `next` branch, resolving the conflicts **between them** yourself: - https://git.eeqj.de/sneak/AutistMask/pulls/171 - https://git.eeqj.de/sneak/AutistMask/pulls/175 - https://git.eeqj.de/sneak/AutistMask/pulls/178 (currently `needs-rebase` — it targeted #169's branch, which has since merged to `main`) - https://git.eeqj.de/sneak/AutistMask/pulls/185 (currently `needs-rework`; include it only if its rework completes, otherwise leave it out and note why) `TODO.md` will conflict across most of them; #178's edit is deliberately a single insert at the top of Completed Steps to make that trivial. ## Definition of done - One `next` branch containing the included PRs as separate issue-closing commits, each message ending ` (closes #N)`. - Exactly ONE open PR in this repo: `next` -> `main`, titled for the milestone. - `make check` green on the combined result, and `make build` still produces release artifacts with `DEBUG` off — the guard added by #178 must pass against the consolidated tree, not just its own branch. - Every superseded PR closed with a comment saying where its work went, and its branch deleted. - Nothing lost: confirm each original PR's commits are represented in `next` before closing it. ## Model going forward `next` is the branch for the NEXT MILESTONE, not the next release; `main` changes between releases as milestones land. Every worker works in its own clone, pulls `next` before starting, and pulls and resolves conflicts itself immediately before pushing. Exactly one open PR in this repo at all times from now on.

clawbot commented

2026-08-10 14:46:51 +02:00

Correction to the rule as I originally stated it. sneak, 2026-08-10:

> you can have multiple open PRs per repo if the milestone on next is completed and hasn't been merged to main yet. you can work on the next milestone off of next on a new PR (mark wip). i just don't want one PR per small feature branch

So the target is not "exactly one open PR, always" — it is one PR per milestone, never one per feature branch. A second open PR is legitimate when a finished milestone PR is waiting on sneak and the following milestone has started off next (not off main) under a WIP: title prefix.

The consolidation work here is unchanged: these are per-issue PRs, which is exactly the shape he does not want.

Also done, so nobody has to remember not to merge mid-consolidation: every open PR in this repo is now titled WIP: …, labelled needs-rebase, and assigned to clawbot. Strip the prefix and reassign only when the milestone PR is genuinely ready. His instruction: "don't tell me not to merge things, rename the PRs with WIP: prefix so they aren't mergeable."

Correction to the rule as I originally stated it. sneak, 2026-08-10: > you can have multiple open PRs per repo if the milestone on `next` is completed and hasn't been merged to `main` yet. you can work on the next milestone off of `next` on a new PR (mark wip). i just don't want one PR per small feature branch So the target is not "exactly one open PR, always" — it is **one PR per milestone, never one per feature branch**. A second open PR is legitimate when a finished milestone PR is waiting on sneak and the following milestone has started off `next` (not off `main`) under a `WIP: ` title prefix. The consolidation work here is unchanged: these are per-issue PRs, which is exactly the shape he does not want. Also done, so nobody has to remember not to merge mid-consolidation: every open PR in this repo is now titled `WIP: …`, labelled `needs-rebase`, and assigned to `clawbot`. Strip the prefix and reassign only when the milestone PR is genuinely ready. His instruction: "don't tell me not to merge things, rename the PRs with WIP: prefix so they aren't mergeable."

clawbot commented

2026-08-10 15:20:09 +02:00

Superseded. sneak, 2026-08-10: "branch and pr per issue, landing on next, squash merged by manager on successful review. manager owns dispatching workers to resolve merge conflicts. next is always ready for me to merge to main without notice." And: "manager merges the pr to next i mean, not directly with git."

So do NOT consolidate or close these PRs. Retarget each to base next, squash-merge it there through Gitea on a passed review, and dispatch a worker for any that will not merge cleanly. main is only ever touched by the milestone PR from next, which sneak merges.

Feature branches may be red; next and main must stay green. Create next from main if it does not exist here yet. Drop the WIP: prefixes once retargeted.

Superseded. sneak, 2026-08-10: "branch and pr per issue, landing on next, squash merged by manager on successful review. manager owns dispatching workers to resolve merge conflicts. next is always ready for me to merge to main without notice." And: "manager merges the pr to next i mean, not directly with git." So do NOT consolidate or close these PRs. Retarget each to base `next`, squash-merge it there through Gitea on a passed review, and dispatch a worker for any that will not merge cleanly. `main` is only ever touched by the milestone PR from `next`, which sneak merges. Feature branches may be red; `next` and `main` must stay green. Create `next` from `main` if it does not exist here yet. Drop the `WIP: ` prefixes once retargeted.

clawbot commented

2026-08-10 16:16:15 +02:00

Done, in the corrected shape: next created from main, all four PRs retargeted to base next, rebased by a worker each, and squash-merged into next through the tracker in this order — #185, #175, #171, #178. No PR was closed or consolidated; each kept its own branch, review history and closing commit, and each branch is now deleted.

next at e9fa8be: make check green (7 suites, 143 tests), make build green with dist/chrome/ and dist/firefox/ produced and all four bundles verified autistmask-build-debug=off, so the guard from #178 passes against the consolidated tree and not just its own branch.

The milestone PR is #190, merge-ready and assigned to you.

Each of the four kept the PASS review it already had; the reviewed content was verified byte-identical after rebase in three cases, and #178 — whose rebase dropped an already-landed commit and resolved Makefile/README.md — got a fresh independent review that also passed.

Done, in the corrected shape: `next` created from `main`, all four PRs retargeted to base `next`, rebased by a worker each, and squash-merged into `next` through the tracker in this order — https://git.eeqj.de/sneak/AutistMask/pulls/185, https://git.eeqj.de/sneak/AutistMask/pulls/175, https://git.eeqj.de/sneak/AutistMask/pulls/171, https://git.eeqj.de/sneak/AutistMask/pulls/178. No PR was closed or consolidated; each kept its own branch, review history and closing commit, and each branch is now deleted. `next` at `e9fa8be`: `make check` green (7 suites, 143 tests), `make build` green with `dist/chrome/` and `dist/firefox/` produced and all four bundles verified `autistmask-build-debug=off`, so the guard from https://git.eeqj.de/sneak/AutistMask/pulls/178 passes against the consolidated tree and not just its own branch. The milestone PR is https://git.eeqj.de/sneak/AutistMask/pulls/190, `merge-ready` and assigned to you. Each of the four kept the PASS review it already had; the reviewed content was verified byte-identical after rebase in three cases, and https://git.eeqj.de/sneak/AutistMask/pulls/178 — whose rebase dropped an already-landed commit and resolved `Makefile`/`README.md` — got a fresh independent review that also passed.

clawbot closed this issue

2026-08-10 16:16:18 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/AutistMask#189