Skip to main content
A change request proposes moving one branch into another. ReasonOS computes its diff from its own synced copy of the repository, so change requests work for any project — a repository hosted on ReasonOS or any plain git remote — with no code host connected and no branch node running. Two properties are worth knowing before anything else:
  • The diff is pinned. A change request records the exact commits it was opened against, so the review you read is reproducible — a later push to the source branch doesn’t silently rewrite a review that already happened.
  • Review data survives force pushes honestly. Threads and approvals carry the commit they were made against. When the branch is rewritten (stacked branches restack constantly), they are marked outdated instead of sliding onto code nobody wrote.

​
Opening a change request

​
From the product

Code → Change requests → New change request is a compare screen: pick the source and target branches and the diff appears immediately, with per-file line counts. Only when you ask to create does it want a title (drafted from the branch name — feature/payments-api becomes “Payments api”) and a markdown description. Create draft opens it as a draft — visible, but explicitly not ready and never mergeable until you press Ready for review. A change request needs two different branches with something between them — identical branches are refused with a message, not an empty review.

​
From the CLI

rbs stack submit pushes each branch of a stack and opens (or updates) one change request per branch, each targeting the branch below it rather than trunk — reviewers see one small diff per request instead of the accumulated sum:
Re-running submit is safe: unchanged branches are skipped, existing requests are updated in place, and when the bottom of a stack lands the request above it is retargeted rather than reopened. See Stacked branches for the full workflow, including the one-time rbs stack init --project <name> setup.

​
The list

The Change requests tab filters with a search grammar alongside the Open / Closed tabs:
Open requests that belong to one stack render as a grouped block — top of the stack first, joined by a spine — so a stack reads as one unit of work in the list, exactly the way the review screen draws it.

​
The review screen

A change request is one scrolling page: title and status at the top, then the stack, the description, and the discussion, with every file’s diff following in the same scroll. A file tree runs down the left; a progress counter tracks which files you’ve marked Viewed. Commenting:
  • Click a line’s comment gutter to start a thread on that line — or drag down the gutter to comment on a range of lines.
  • Comments you write while reading become pending and are submitted together with your review, so the author gets one notification, not twelve. You can edit or delete your own comments afterwards.
  • Threads are resolved explicitly, and a thread whose code has since been rewritten says outdated rather than pointing at the wrong lines.
When you’re done, Review changes submits everything with a verdict: Approvals are recorded against the commit they were given for. If the branch is pushed again, the screen says how many approvals predate the current commit — and a ruleset can make stale approvals stop counting entirely. The Reviewers card asks someone to review: the picker offers organization members who aren’t the author and haven’t been asked already. What’s waiting on each person shows up in their inbox.

​
Stacks in review

When the source branch is part of a stack, the review screen shows the whole chain — every branch from the top of the stack down to trunk, with each request’s state — and clicking an entry walks to that request’s review. Copy stack copies the chain as markdown for pasting anywhere. The stack graph is read from the repository itself, so a stack pushed from any machine renders here without any registration step.

​
Merging

The merge box shows everything that bears on “can this land” before you press the button:
  • the review verdict (approvals, changes requested, pending reviewers)
  • unresolved threads
  • whether the branches merge cleanly — conflicts list the conflicting files
  • required checks: each required CI workflow’s state at the current revision, linking to its run — a check that hasn’t run reports as pending, never as passing
  • any unmet branch rules, named with the ruleset that requires them
Merge change request lands a merge commit on the target branch, server-side — no branch node needed. The merge is guarded: if the target branch moves between the check and your click, the merge aborts and asks you to re-check rather than overwriting the racing push, and branch rules are enforced at the same moment. A merge behaves like a push to the target branch, so CI workflows watching that branch run.
The merge button works for ReasonOS-hosted repositories, and merges land as merge commits today — squash and rebase methods are in progress. For a project that mirrors an external remote, ReasonOS records intent instead: merge upstream or from a workspace as you normally would, then Mark as merged on the request.
The other exits: Close closes without merging (a closed request can be reopened), and Convert to draft takes an open request back out of review. Merged is terminal — the commits are on the target branch, so there is nothing to reopen.

​
The inbox

Your organization’s Inbox answers the question a project’s list can’t: what is anybody waiting on me for, across every project? Four groups, in the order you’d act on them:
  1. Needs your review — somebody asked you, and is waiting
  2. Changes requested — yours; a reviewer wants something changed
  3. Approved — yours, reviewed, nothing outstanding
  4. Waiting on others — yours; the ball is in somebody else’s court
Every row is live state read from the request itself — an item leaves the inbox because the work moved, never because you clicked “mark read”.