> ## Documentation Index > Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt > Use this file to discover all available pages before exploring further. # Change requests > Propose a branch for review, discuss it line by line with commit-pinned threads, and land it — from the product or from rbs stack submit. 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`](/workflow/stacks) 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: ```bash theme={null} rbs stack submit --stack # the whole stack, bottom-up rbs stack submit --draft # open new requests as drafts rbs stack submit --update-only # update existing requests, never open new ones ``` 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](/workflow/stacks) for the full workflow, including the one-time `rbs stack init --project ` setup. ## The list The Change requests tab filters with a search grammar alongside the Open / Closed tabs: ```text theme={null} is:open is:draft is:merged author:ada base:main head:feature #12 free text ``` 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: | Verdict | Meaning | | ------------------- | ----------------------------------------------------- | | **Comment** | General feedback, no explicit approval | | **Approve** | Approve merging these changes | | **Request changes** | One blocking verdict outranks any number of approvals | 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](#the-inbox). ### Stacks in review When the source branch is part of a [stack](/workflow/stacks), 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](/ci/overview)'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](/platform/git#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".