Reviews, approvals, merging and editing

Send your review with one click, see where a pull request stands, and change its title, reviewers or labels without leaving Revue.

You read the diff and leave comments (see Comments, threads and drafts). This page is about what comes after: sending the review, approving, and keeping an eye on checks and conflicts. It also covers editing a pull request.

Submit your review#

When you're done reading, click Review at the top right of the pull request, or press Ctrl+Enter (Cmd+Enter on macOS). When you have comments waiting to be sent, the button shows how many, e.g. Review · 3.

The Submit review dialog opens:

Write a summary in the box at the top, if you want one. It's Markdown, with the same toolbar and preview as any comment box.
Check the list below it: it says how many inline comments will be published and shows the first ones (file, line, first line of text).
Click one of the three buttons:
- Comment: feedback only, no verdict.
- Approve: you're happy with it.
- Request changes: it needs more work before it can go in.

The dialog stays open with a spinner on the button until the review is in. Then it closes, a notice confirms it (Approved ✓, Changes requested or Comment posted) and the pull request reloads with your comments in place.

Approve and Request changes are greyed out on your own pull request: the services don't let you approve your own work. Comment always works.

Your summary is saved as you type#

The summary is saved to disk on every keystroke, together with the pull request's other drafts. Close the dialog, close Revue, come back tomorrow: it's still there. It's cleared only once a review goes through.

Advanced: what happens when submitting fails

Nothing is lost. If the service refuses the review, a notice says Submitting failed — your drafts are safe. with the reason. Your drafts and summary stay as they were; fix the problem and submit again.
Bitbucket stops part-way. Bitbucket has no single "post a review" request, so Revue posts each comment in turn. If one fails, the notice says Submitting stopped after N comments — the rest are still drafts. The ones already posted leave your drafts; the rest stay drafts to send again.
Lines that changed since you commented. A comment written on an older commit is moved to the newest commit before it's posted. If its line no longer exists there, it's posted as a comment on the whole file, quoting where it was. The confirmation then adds e.g. · 2 comments moved to file level (lines changed since). How this works is on Comments, threads and drafts.
Closing the dialog mid-submit doesn't cancel the review: it still goes in, and your drafts are cleared when it does.
An empty Comment (no summary, no inline comments) sends nothing to the service.

Notify in Slack#

With Slack connected, the dialog has a Notify in Slack box. Tick it, pick the Slack thread that links to the pull request and who to tag, and once the review is in Revue replies there as you, e.g. "@Ann I approved your pull request #12". The review buttons wait until the thread and the person are settled. A failed Slack reply never fails the review: you get a separate notice with Retry.

Everything about it (finding threads, finding people, message wording) is on the Slack page.

Approvals on each service#

Each service records your verdict a little differently. Revue sends the same three buttons to all of them.

Per service

	GitHub	Bitbucket Cloud	Forgejo, Codeberg, Gitea
How a review is sent	One review with all its inline comments. File-level comments are posted just before it.	Each comment one by one, then the summary as a plain comment, then the approval or change request.	One review with its line comments, summary and verdict.
File-level comments	Posted as file comments.	Posted as file comments.	Added to the review summary, each under its file's name in bold.
Approve	An approving review.	Approves the pull request. If you had requested changes, that's withdrawn first.	An approving review.
Request changes	A "changes requested" review.	Requests changes. If you had approved, the approval is withdrawn first.	A "changes requested" review.
Comment	A comment review.	Only the comments and summary, no verdict.	A comment review.

GitHub's pending reviews. If you started a review on github.com and didn't submit it, Revue shows a yellow banner: You have a pending review on GitHub with N comments. Its buttons:

Submit… opens the Submit review dialog. The dialog warns Your pending review on GitHub (N comments) is submitted with it. Your Revue drafts are added to that review and it's submitted with your verdict.
Discard deletes the pending review and its comments from GitHub without publishing them (you're asked first).
Open on GitHub shows it on the website.

While such a pending review exists, a comment you post with Comment now or a reply goes into it rather than out, as GitHub requires. Revue tells you so the first time, with a Submit review… button.

Where a pull request stands#

The header shows the pull request's state at a glance:

State: Open, Draft, Merged or Closed, coloured, before the title.
Checks: Checks passed, Checks failed or Checks running. Click it to open the Checks tab.
Review decision: Approved, Changes requested or Review required.
Conflicts, in red, when the pull request can't be merged cleanly into its base branch.
New commits, in blue, when someone pushed since you loaded it. Click it to load them.

Advanced: how the review decision is worked out

GitHub gives it directly.
Bitbucket: Changes requested if any participant requested changes, else Approved if anyone approved, else Review required when there are reviewers.
Forgejo: each reviewer's latest verdict counts (a dismissed review cancels theirs). Changes requested wins over Approved; Review required when reviews are requested and no verdict is in.

Conflicts#

GitHub, Forgejo and their kin only say that a pull request conflicts, not where. Revue works out where: it compares the pull request's own changes with what changed on the base branch since they parted, and finds the lines both sides change.

Hover the Conflicts badge to see the files and lines, e.g. src/app.rs lines 40–52. Up to 12 files are listed, then "and N more".
Click it to jump to the first conflicting line in the diff.

To resolve conflicts, merge or rebase the base branch into the pull request's branch in your clone and push (see Clones, worktrees and opening in your tools). Revue doesn't resolve them itself.

Advanced: conflict details

Lines next to each other also count, because Git won't merge those either.
A binary file, or one deleted on one side, is listed as the whole file.
While Revue works it out, the hover says Finding where…. If the changes don't show where (for example the conflict comes from a rename), it says Where isn't clear from the changes: try merging the base branch in.
It's worked out again only when the pull request's head or base commit changes.
Bitbucket doesn't report whether a pull request conflicts, so the badge never shows for Bitbucket pull requests.

Checks#

The Checks tab (key 6) lists every check run and build status reported on the pull request's newest commit, and below them those of its earlier commits (see Earlier commits and earlier runs). Failures come first, then the running ones, then the rest, by name. The tab's title shows how many passed and failed.

At the top, a summary such as 2 failing · 1 in progress · 14 passed and the commit it's for. While checks are running, a Live marker shows: Revue updates them every 20 seconds while the pull request is on screen. The refresh button next to it (Refresh the checks only) reloads just the checks.

Click a check to open it. Depending on what the service and the CI reported, you see:

its summary and details (Markdown),
its annotations: file and line, title and message, coloured by level,
for GitHub Actions jobs, a Load log button.

The external-link button on each row (Open in browser) opens the check's own page. A check with nothing to show says This check reported no details.

Earlier commits and earlier runs#

When the pull request has more than one commit, the checks are grouped by commit: the newest (Head commit) first and open, then the earlier ones, newest first and closed. Each group's header shows the commit's short hash, its title and how its checks came out (the worst of them: failed, running, passed). Click a header to open or close the group; an earlier commit's checks are loaded when you first open it, so you can see what failed on an earlier push.

A check that ran more than once on a commit (a re-run job, a workflow triggered again, a status set again) shows 2 earlier runs (or however many) under it. Click it to list them, newest first, each with its result, when it ran, its page and, for GitHub Actions jobs, its log. What counts as the check's result (in the summary, the tab's title, the header's badge and the merge requirements) is still its latest run on the newest commit.

What each service shows:

GitHub: every check run (re-runs and workflows triggered again included) and every status set.
Forgejo: every status set on the commit, so a job run again shows how its earlier runs ended.
Bitbucket: one status per build; Bitbucket updates it in place, so a build run again shows an earlier run only when it reported under a new key with the same name.

A status set to pending before a later one isn't listed: CI sets one as a run starts, and it's that run's, not one of its own.

Reading a log#

Load log fetches a GitHub Actions job's log, only when you ask, as logs can be large. Revue cleans it up (no timestamps or colour codes, workflow groups and errors marked) and shows the last 400 lines; Show all shows the rest.

Type in Search the log… to see only the matching lines, highlighted. The search ignores case unless you type a capital letter. Reload fetches the log again, for example after a job finished.

Per service and limits

GitHub: check runs and commit statuses, with summaries, annotations, and logs for GitHub Actions jobs.
Bitbucket: the commit's build statuses.
Forgejo: the commit's statuses (including Forgejo Actions'), with their description and link.
Logs exist only for GitHub Actions. Other checks open on their own page with Open in browser.
A search shows at most 2000 matching lines (First 2000 of N matching lines).
Revue doesn't re-run checks. Re-run them on the service's website or in your CI.

Edit a pull request#

Click the pencil next to the title (Edit the title, description, reviewers, labels…) to open Edit pull request. There you can change:

Title and Description (the description has the full Markdown editor),
Merges into: the base branch. Click it and pick another (The branch it merges into: pick another),
Draft: whether it's still a draft (Not ready for review yet),
Reviewers: Add reviewer, or click a name to take it off (Don't ask for their review),
Assignees: Assign, or click a name to Unassign,
Labels: Add label, or click one to take it off (or use Labels in the header, which saves each click right away; see Reviewing the diff),
Milestone: pick one, or No milestone.

Click Save. Only what you changed is sent. The dialog closes, a notice says Pull request updated and the pull request reloads. If the service refuses a change, the dialog stays open with the error and your edits. Cancel closes without saving.

Every picker lists all the choices as soon as it opens; type to narrow them. Press Enter in a picker to take the first match. Reviewers, assignees and labels stay open so you can add several.

Per service

Field	GitHub	Bitbucket Cloud	Forgejo, Codeberg, Gitea
Title, description, base branch, reviewers	Yes	Yes	Yes
Draft	Yes	Yes	Yes, through the title: a draft's title starts with `WIP:`
Assignees, labels, milestone	Yes	Not shown (Bitbucket has none)	Yes

Forgejo drafts: Forgejo marks a draft by starting its title with WIP: (or [WIP]). The dialog shows the title without it and turns it into the Draft box; saving puts WIP: back on or takes it off. A new title keeps a draft a draft.
Labels and milestones lists show up to 100 of each (open milestones only). A picker shows up to 200 rows; type to find the rest.
A pull request must have a title: an empty one shows A pull request needs a title.
The pencil shows on every pull request. Whether a change is allowed is up to the service (usually the author and people who can write to the repository).

Ask for a review again#

After you've pushed changes in answer to a review, Request review asks for one: it requests reviews again on the service (people who reviewed before start ticked) and, with Slack connected, posts "@bob please review …" in the pull request's Slack thread; see Slack. On a pull request you wrote (or have commits in), the header's main button is Request review, with Review in the ⋯ menu beside it; as a reviewer it's the other way round. The Slack threads tab has the same, as Ask for a review.

Without Slack, use the Reviewers field in Edit a pull request to request reviews.

Merging#

Press m, or click Merge at the top right of your own pull request (on someone else's it's Merge… in the ⋯ menu). The icon on the button is coloured by how the pull request stands: green when it can be merged, amber while it waits for something (checks still running), red when something blocks it. Hover over it to see what.

The Merge pull request dialog shows what the service's own merge box would, read from GitHub, Forgejo or Bitbucket:

At the top, the verdict: Ready to merge, Waiting for the requirements or Merging is blocked, with what holds it back, and the branches it merges.
Requirements: every condition the branch's rules set, met or not, each marked Required when it blocks the merge:
- Reviews: how many approvals there are of those required (e.g. 1 of 2 required approvals), who asked for changes, whose review is still asked for, and what else the rules want (code owners, an approval after the last push).
- Checks: failing first, the required ones marked, and the required ones that haven't reported yet (Expected: waiting for it to be reported). Click a check to open its page; Checks tab takes you to the full logs.
- Conversations that must be resolved, up to date with the base branch, conflicts (with the files and lines, as on the header's badge), draft, and on Bitbucket its own merge checks and open tasks.
- Where something here fixes it, a button beside it does: Update branch (merge the base branch in, or rebase onto it), Ready for review, Show them.
Merge method: the methods the repository and the branch's rules allow, the service's default picked, each with what it does to the commits. The ones you can't use are listed greyed out with why, such as Not allowed by the branch's rules (a GitHub ruleset allowing only squash) or Not enabled for this repository.
Commit title and Commit message, prefilled as the service would, for a method that writes a commit. Switching methods keeps what you typed for each.
Delete the branch … after merging, ticked as the repository has it, when the service doesn't delete it itself.

The main button does what the service offers as the pull request stands:

Ready: it merges with the method picked (e.g. Squash and merge).
Not ready, on GitHub with auto-merge allowed: Enable auto-merge merges it once the requirements are met. When it's on, the top says so and Turn off auto-merge turns it off. On Forgejo, the same merges it when the checks succeed.
On a branch with a GitHub merge queue: Add to the merge queue (or Merge when ready); once queued, the top shows its position and Remove from the queue.
If you're an administrator who may bypass the rules (GitHub, or Forgejo's force merge), a tick box lets you merge anyway; the button turns red.

If the service refuses the merge, its reason shows in the dialog. Once merged, the dialog closes and the header shows Merged. While the dialog is open it follows the pull request: checks finishing or a branch update show up in it. Administrators also get Branch rules on …, which opens the rules on the service, and every dialog has Open on ….

Revue doesn't close or reopen pull requests: press o to do that on the service.

For a chain of pull requests that build on each other, see Stacked pull requests for the order to merge them in.

Guide: Review a pull request from start to finish#

Open the pull request: pick it from the list, or press Ctrl+K (Cmd+K on macOS) and paste its link.
Glance at the header: is it a Draft, do the Checks pass, are there Conflicts?
Read the description and earlier discussion on the Conversation tab (2).
Go to the Files tab (1). If you reviewed it before, press r to see only what changed since your last review.
Read file by file: j and k move between files, n and p between changes, v marks a file viewed and jumps to the next.
To comment, drag over line numbers in the gutter (or select lines and press c), write, and click Add to review. Your comment is saved as a draft at once.
Answer open threads: ] and [ jump between them; reply or resolve inline.
If a check failed, open the Checks tab (6), click the failing check and Load log to see why.
Press Ctrl+Enter (Cmd+Enter on macOS) to open Submit review.
Write a short summary.
Tick Notify in Slack if you want the author told there.
Click Approve, Request changes or Comment.
When it's approved and the checks pass, press m and merge it.

More on each step: Reviewing the diff, Comments, threads and drafts and Keyboard shortcuts.