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
editProblem | 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 |
|
Review a change to a project |
|
|
Find changes for review |
|
|
Block a change from merging | -2 |
|
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 |
|
|
Mark changes as dependent on others | Use Depends-On with a Change-Id |
|
Mark a change as WIP | Click "Mark as work in progress" on patch |
|
Attach a change to a ticket | Bug: Txxx |
|
Workflow comparisons
editReview scores
editGerrit 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
editGerrit 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
editGitlab, 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.
-
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.
-
discussion on Gerrit, as individual comments
-
discussion on GitLab, as individual comments
-
discussion on GitLab, as one thread with three comments