GitLab/Gerrit to GitLab

This is intended as a concise reference document for experienced users of Gerrit, explaining how concepts and workflows map to GitLab features, and indexing into the rest of our guides as well as upstream docs.

Problem / feature matrix

edit
Comparison of Gerrit and GitLab
Problem Gerrit GitLab
You want to... Pithy statement(s) of Gerrit solution Pithy statement(s) of GitLab solutions, links to documentation, etc.
Make changes to a project Create a patch for review
Request review for your changes Assign or CC reviewers to a patch
  • Assign the merge request to a primary reviewer
  • @mention the usernames of desired reviewers in MR description or a comment
Review a change to a project
  • Comment on a patchset
  • +1 or -1 to indicate feelings
  • +2 / -2 to accept or reject
  • Comment on a merge request; use suggestions for minor changes
  • Use approvals and reactions to indicate feelings
  • Where appropriate, push additional commits with fixes to work branch
  • Merge or close request
  • See also: Code review
  • Upstream: Reviewing and managing merge requests
Find changes for review
  • Dashboards
  • Set up e-mail notifications
  • Check lists of changes by project or author
Block a change from merging -2
  • No exact equivalent
  • Repo may require discussions be resolved before merges
  • React with a thumbs-down
  • Close merge request
Rewrite change before merge Check out and amend change commit, submit as new patchset
(Re)-run tests

Comment "recheck"

CI / CD → Pipelines → Run Pipeline

See if a change has merged Indicator in patch set and overview Indicator in patch set and line in merge request list
Know who merged a change List item in patch set Status line in merge request and merge request list
Backport / cherry-pick a change Click cherry-pick and select branch on patch
Group changes within or across projects
  • Use a topic
  • Use Depends-On with a Change-Id from another change
  • No exact equivalent
  • Group logically-related changes within a merge request
  • Labels can be used within a project or, but have to be registered with the projects
  • Upstream: Labels
Mark changes as dependent on others Use Depends-On with a Change-Id
  • No exact equivalent
  • Within a project, branch from a branch
Mark a change as WIP Click "Mark as work in progress" on patch
Attach a change to a ticket Bug: Txxx

Workflow comparisons

edit

Review scores

edit

Gerrit supports code reviews ranging from -2 to +2 on changes. On GitLab, these roughly correspond to:

-2
No direct equivalent. If you want to make sure that no one fails to notice your objection before merging the change, you can edit the merge request title or description, e. g. adding the note DNM. Repositories are also likely, by policy, to be configured so that all comment threads must be resolved before merge.
-1
Leave a comment or start a thread with your objection. You may also add a thumbs-down reaction.
0
Leave a comment or start a thread. (On Gerrit, you can also change your vote back to 0 to remove a different vote, such as a +1; in GitLab, this would mean revoking your approval.)
+1
Approve the merge request and/or leave a thumbs-up reaction.
+2
Merge the merge request. (TODO: will we still have a gate-and-submit build and automatic merges?)

Comment and description markup

edit

Gerrit supports some limited markup in review comments, including quotes, lists, and code blocks.

By contrast, GitLab offers GitLab Flavored Markdown, a full-featured Markdown dialect, based on an implementation of the CommonMark specification. This may be used in both merge request descriptions and review comments. It allows for rich linking, syntax-highlighted code blocks, block quotations, embedded images, and many other features.

Comments and threads

edit

Gitlab, like Gerrit, supports threaded discussion. Replies can be linked with a comment, and a whole thread can be marked as resolved.

On Gerrit, resolving/unresolving a thread is only possible when commenting on it, and so it is conventional to resolve a thread with a comment “Done” if there is nothing else to say.

On GitLab, on the other hand, this is not necessary: A thread can be marked as resolved or unresolved without requiring a new comment.

GitLab also supports threaded discussion not just on file-level comments, but also on top-level comments that apply to the whole merge request / change.