GitLab/Gerrit to GitLab

Policy Workflows Project setup assumptions Registering an account on GitLab Hosting a project on GitLab Pipeline conversion Mirroring projects Configuring CI Publishing documentation Code review Making a merge request Squashing Managing security patches Deploying services to production Gerrit to GitLab Localization updates wikitech:GitLab GitLab implementation

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

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	Create a work branch and submit as a merge request See also: Making a merge request Upstream: Getting started with merge requests
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	Watch projects you're interested in Search for open merge requests See also: Finding merge requests to review Upstream: Reviewing and managing merge requests
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	Check out work branch and push additional commits Add comments with suggestions to merge request
(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	After merge, click cherry-pick and select branch Upstream: Cherry-pick changes
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 See also: Squashing 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	Prefix merge request title with Draft: Upstream: Draft merge requests
Attach a change to a ticket	Bug: Txxx	No exact equivalent See also task T265617

Workflow comparisons

Review scores

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

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

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.

• Comparison of a file comment thread on Gerrit and GitLab
• 
  discussion on Gerrit, with final “Done” comment
• 
  discussion on GitLab, without “Done”

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.

• Comparison of a simple top-level discussion on Gerrit and GitLab
• 
  discussion on Gerrit, as individual comments
• 
  discussion on GitLab, as individual comments
• 
  discussion on GitLab, as one thread with three comments