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 =

= 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?)

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.