chadtmiller.com/knotless
git that lives in your Atmosphere account
A pull's page shows the stack it is part of
MergedThis pull adds stack_of, which follows the chain through the open pull whose branch a pull targets and through the pull now written on the moving state record. getThread returns the chain as stack. The merge box, the merged timeline and the files page draw it. Lexicons, docs and tests are updated. I found no bugs in the chain logic. It stops on cycles, ignores heads in forks, drops closed pulls, and follows the oldest pull where several share a branch. The unit test covers those cases, and the forge test reads stack after a real squash and move. I read every file in the diff. I did not run anything, and I did not open the screenshots.
One small thing in crates/knotless-serve/src/web/items.rs: the new structs were inserted between ThreadView's doc comment and ThreadView. The comment "dev.knotless.getThread's answer…" now sits on StackView, and ThreadView has none. Move the new block above that comment.
crates/knotless-serve/src/web/items.rslines 138 to 140Outdated
/// `dev.knotless.getThread`'s answer: a pull or an issue, and everything | |
/// said on it. | |
/// `dev.knotless.defs#stackView`. |
These two lines were ThreadView's doc comment. They now attach to StackView, and ThreadView loses its comment. Put the stack structs above them.
Carried forward: the change this pull makes at 935c3095decf3e06f36380c1c16d2a6e637eddc0 is the one reviewed at 748e8bf525897c6a237381884c68e25c965e3769, so that review stands. What is new comes from its base.
9 passed, 1 skipped
What changes
A pull's page shows its stack. A pull built on another pull's branch, or with one built on its own, now lists the whole chain in its merge box: highest first, joined down to the branch it lands on, with this pull marked by a fill. A merged pull keeps the list under its timeline, each row with the commit it landed as.
Its files page says what it leaves out. Above the diff, a line says it shows only what this pull adds, and on what. Links go to the pulls below and above, for reading a stack a layer at a time.
A moved pull remembers what it was moved off. The state record that moves a pull as the one below lands now names that pull in
pull, so the chain survives the landing.getThreadanswersstack, new and optional, built from the items already read, with no extra git or index reads.Changeset: none
Why
Moving pulls as they land took away the only sign of a stack: the base branch. A reviewer of a middle layer needs to see what sits under and over it, and get to them.
Where several pulls target one branch, the oldest is the one followed, rather than drawing a tree: a chain is what the merge queue will land.
How it was checked
A unit test covers the chain from each end, the oldest above, a pull moved off a landed one, retargeting by hand, a closed pull, branches that target each other, and a head in a fork. The forge test reads
stackfromgetThreadafter a real squash and move. Pages checked withjust look, desktop light and phone dark, and svelte-check here. No recorded page holds a stack, so the shots check draws none of this: the pictures below are the states.Shortcomings
Pulls moved before this landed have no
pullon their record, so their stack starts at them. The per-row "Ready" and line counts from the mocks are left out: they need each row's checks at its own head, which belongs with queueing a stack.knotless pull showdoes not print the stack yet. The world behind the shots has no stack, so e2e does not reach it.A fresh critique of the pictures raised points left as they are: the "..." button wrapping on a phone and the merge box's mixed controls are there already; the heading follows its container, a box head on a merged pull and a row in the merge box; Below and Above read as previous and next; "Landed as" on every row keeps a part-landed stack readable.
🤖 Generated with Claude Code