Review UI Overview

Top left, you find the status of the change, and a permalink.

The change status shows the state of the change:

Clicking the star icon bookmarks the change: it turns on email notifications for this change, and the change is added to the list under Your > Starred Changes. They can be queried by the is:starred search operator.

Links menu contains various change related strings for quick copying. Such as: Change Number, URL, Title+Url, etc. The lines in this menu can also be accessed via shortcuts for convenience.

The change metadata block contains detailed information about the change.

Reviewers can be removed from the change by selecting the appropriate option on the chip’s hovercard. Removing a reviewer also removes current votes of the reviewer. The removal of votes is recorded in the change log.

Removing reviewers is protected by permissions:

Submit Requirements describe various conditions that must be fulfilled before the change can be submitted. Hovering over the requirement will show the description of the requirement, as well as additional information, such as: corresponding expression that is being evaluated, who can vote on the related labels etc.

Approving votes are colored green; negative votes are colored red.

For more detail on Submit Requirements see Submit Requirement Configuration page.

Actions buttons are at the top right and in the overflow menu. Depending on the change state and the permissions of the user, different actions are available on the change:

The file list shows the files that are modified in the currently viewed patch set.

In addition to the modified files the file list contains magic files that are generated by Gerrit and which don’t exist in the repository. The magic files contain additional commit data that should be reviewable and allow users to comment on this data. The magic files are always listed first. The following magic files exist:

Every file is accompanied by a number of extra information, such as status (modified, added, deleted, etc.), number of changed lines, type (executable, link, plain), comments and others. Hovering over most icons and columns reveals additional information.

Each file can be expanded to view the contents of the file and diff. For more information see Diff View section.

Instead of the file list, a comments tab can be selected. Comments tab presents comments along with related file/diff snippets. It also offers some filtering opportunities at the top (ex. only unresolved, only comments from user X, etc.)

Checks tab contains results of different "Check Runs" installed by plugins. For more information see Checks API page.

The change screen only presents one pair of patch sets (Patchset A and Patchset B) at a time. A is always an earlier upload than B and serves as a base for diffing when viewing changes in the files. Which patch sets is currently viewed can be seen from the Patch Sets drop-down panel in the change header. If patchset 'A' is not selected a parent commit of patchset 'B' is used by default.

The Download drop-down panel in the change header offers commands and links for downloading the currently viewed patch set.

The available download commands depend on the installed Gerrit plugins. The most popular plugin for download commands, the download-commands plugin, provides commands to checkout, pull and cherry-pick a patch set.

Each command has a copy-to-clipboard icon that allows the command to be copied into the clipboard. This makes it easy to paste and execute the command on a Git command line. Additionally each line can copied to clipboard using number (1..9) of the appropriate line as a keyboard shortcut.

If several download schemes are configured on the server (e.g. SSH and HTTP) there is a drop-down list to switch between the download schemes. Gerrit automatically remembers the download scheme that was last chosen and selects this download scheme the next time the download commands drop-down panel is opened.

The Patch-File links provide the Git patch file for the currently viewed patch set for download. The patch file can be base64 encoded or zipped.

The Archive links allow one to download an archive with the contents of the currently viewed patch set. The archive is offered in several formats (e.g. tar and tbz2); which formats are available depends on the configuration of the server.

For merged changes the Included In drop-down panel is available through the overflow menu at the top. It shows the branches and tags in which the change is included. E.g. if a change fixes a bug, this shows which released versions contain the bug-fix (assuming that every release is tagged).

If there are changes that are related to the currently viewed change they are displayed in the third column of the change screen.

There are several lists of related changes that are displayed in separate sectionsunder each other.

The following sections may be displayed:

The Reply…​ button in the change header allows to reply to the currently viewed patch set; one can add a summary comment, publish inline draft comments, vote on the labels and adjust attention set.

Clicking on the Reply…​ button opens a popup panel.

A text box allows to type a summary comment for the currently viewed patch set. Markdown syntax is supported same as in other Comments.

If the current patch set is viewed, buttons are displayed for each label on which the user is allowed to vote. Voting on non-current patch sets is not possible.

The inline draft comments that will be published are displayed in a separate section so that they can be reviewed before publishing. There are links to navigate to the inline comments which can be used if a comment needs to be edited.

The SEND button publishes the comments and the votes.

If a user can approve a label that is still required, a quick approve button appears in the change header that allows to add this missing approval by a single click. The quick approve button only appears if there is a single label that is still required and can be approved by the user.

E.g. if a change requires approvals on the 'Code-Review' and the 'Verified' labels, and there is already a '+1 Verified' vote, then if the user is allowed to vote the max score on 'Code-Review', a Code-Review+2 quick approve button appears that approves the 'Code-Review' label if clicked.

Using the quick approve button also publishes all inline draft comments; a summary comment is only added if the reply popup panel is open when the quick approve button is clicked.

The history of the change can be seen in the lower part of the screen.

The log contains messages for all kinds of change updates, e.g. a message is added when a new patch set is uploaded or when a review was done.

The change screen automatically polls for updates to the currently viewed change. If there is an update the user is informed by a popup panel in the bottom right corner.

The polling frequency depends on the server configuration; by default it is 30 seconds. Polling may also be completely disabled by the administrator.

Gerrit plugins may extend the change screen. Java plugins in the backend can add additional actions to the triple-dot menu block. Frontend plugins can change the UI controls in arbitrary ways.

In the diff view, Gerrit shows added and removed contents with green and red colors respectively.

When comparing two patch-sets against each other, and if both patch-sets have different bases (parents), Gerrit also identifies parts of the diff that were modified due to rebase. Those are called “rebase edits” and are highlighted with different colors.

Gerrit identifies rebase edits by also inspecting the diff between parents, and if it detects an edit between parents that’s also an edit between the patch-sets (after mapping/transforming the edit), then it marks it as a rebase edit. This first diffs both patch-sets to identify all edits, then potentially excludes some of them if they were identified as rebase edits.

If all edits in a file were due to rebase, the file is skipped and is not shown among the list of files in the ‘files tab’.

A rebase might be hazardous in some cases. One such example is when users have a stack of changes (e.g. two changes as in the below figure) then squash both changes and upload the resulting commit as patch-set 2. In this case, PS1 and PS2 are identical and Gerrit shows an empty diff, which is a correct diff but it’s hiding the fact that new content got implicitly merged into this change from the parent change.

Inline comments are displayed directly in the patch file under the code that is commented. Inline comments can be placed on lines or on code blocks.

If an inline comment relates to a code block, this code block is highlighted by a yellow background.

Code blocks with comments may overlap. This means it is possible to attach several comments to the same code.

The comments support markdown. It follows the CommonMark spec, except inline images and direct HTML are not rendered and kept as plaintext.

The lines of the patch file are linkable: simply append '#<linenumber>' to the URL, or click on the line-number. This not only opens a draft comment box, but also sets the URL fragment.

Clicking on the Reply button opens an editor to type the reply.

Previous comment can be quoted using "Quote" button. A new draft would be open on the same comment thread with the text of the previoused comment quoted using markdown syntax.

Comments are first saved as drafts, and you can revisit the drafts as you read through code review. Finally, they will be published by clicking the "Reply".

Comments can be unresolved (something should be changed) or resolved (informational). If you have addressed an unresolved comment in a next patchset, you can quickly resolve the comment by clicking "Done" (if it was resolved in a next patchset) or "Ack" (if you acknowledge the comment, but don’t want to make changes).

To add a new inline comment there are several possibilities:

There are many ways to select code for commenting on it. The most frequently used methods are:

For typing the new comment, a new comment box is shown under the code that is commented.

Clicking on the Save button saves the new comment as a draft. To make it visible to other users it must be published from the change screen by replying to the change.

Comments can contain suggested fixes.

Clicking "Suggest Fix" will insert a special code-block in the text of the comment. The contents of this code block will replace the lines the comment is attached to (what gets highlighted when hovering over comment).

The author of the change can then preview and apply the change. This will created a new patchset with changes applied.

File level comments are added by clicking the 'File' header at the top of the file.

There are several options to control how patch diffs should be rendered. Users can configure their preferences in the diff preferences. The diff preferences can be accessed by clicking on the settings icon in the screen header.

The following diff preferences can be configured: