chadtmiller.com/knotless
git that lives in your Atmosphere account
1
10
A stacked pull merges right after the one below it
Merged Approved
This moves the fresh reads of queue, state and auto-merge records into Target::around. Every action that starts from one item now sees a pull that a merge just moved onto its base, instead of failing with "has no branch …". I read fresh_entries, freshened and newest, and the change holds up.
set_state:freshenedreplaces entries by URI, so adding the caller's own newest states afterwards creates no duplicates. That includes the case where the caller is the owner, and it matches what the old code did.- Failure behaviour: a fresh read that fails or times out adds nothing, so the worst case is the old behaviour, plus up to
FRESH_WAITof delay. - Housekeeping: the changeset and the
collaboration.mdupdate are there, as AGENTS.md asks.
I haven't run the tests. The author says forks_pulls_reviews_and_merges now passes locally and leaves the rest to CI.
All checks have passed
8 passed, 3 skipped
Merged as fdf763b
Merging (or diffing) a stacked pull right after the one below it landed failed with "has no branch …" until the appview heard of the move. This is the cause of
forks_pulls_reviews_and_mergesfailing on spaces now and then (it failed twice in one run on pull 3mzy6dxbqdbfy, and every time locally). Small change to how an action reads the item it starts from.Claude Opus 5.5
What changes
Target::around, which every action that starts from one pull or issue reads it through (merge, compare, diff, branch update, comment, retarget, state changes), now reads the newest queue, state and auto-merge records of the owner, collaborators and the queue's runner from their own accounts (fresh_entries, as the merge queue andset_statealready did), beside the appview's index.set_state, which read them itself, now only adds the caller's own newest states.Why
Merging the pull below deletes its branch and writes a state record moving each pull above onto its base. The next merge or diff read the pull above from the appview, which had not yet indexed that record, so it still targeted the deleted branch:
knotless://…/forkable has no branch tidy(and… lowforpull diff) incrates/knotless-serve/tests/forge.rs. A person merging a stack by hand hits the same error. The records that move a pull were already read fresh where the merge queue reads them; doing the same inaroundcovers every action at once rather than each caller.How it was checked
forks_pulls_reviews_and_mergesagainst the spaces alpha locally: failed on every run with main's code, passes with this. The rest is left to CI.Shortcomings
Each of these actions now also reads three collections from each writer's account (bounded by
FRESH_WAIT, side by side with the appview), a few more round trips per command; the pages' reads are not touched.