- Places you can add comments
- Mentions
- Add a comment to a merge request diff
- Reply to a comment by sending email
- Edit a comment
- Prevent comments by locking the discussion
- Add an internal note
- Show only comments
- Change activity sort order
- View description change history
- Assign an issue to the commenting user
- Create a thread by replying to a standard comment
- Create a thread without replying to a comment
- Resolve a thread
Comments and threads
- Paginated merge request discussions introduced in GitLab 15.1 with a flag named
paginated_mr_discussions
. Disabled by default. - Paginated merge request discussions enabled on GitLab.com in GitLab 15.2.
- Paginated merge request discussions enabled on self-managed in GitLab 15.3.
- Paginated merge request discussions generally available in GitLab 15.8. Feature flag
paginated_mr_discussions
removed.
GitLab encourages communication through comments, threads, and Code Suggestions.
Two types of comments are available:
- A standard comment.
- A comment in a thread, which can be resolved.
In a comment, you can enter Markdown and use quick actions.
You can suggest code changes in your commit diff comment, which the user can accept through the user interface.
Places you can add comments
You can create comments in places like:
- Commit diffs
- Commits
- Designs
- Epics
- Issues
- Merge requests
- Snippets
- Tasks
- OKRs
Each object can have as many as 5,000 comments.
Mentions
You can mention a user or a group (including subgroups) in your GitLab
instance with @username
or @groupname
. All mentioned users are notified with to-do items and emails.
Users can change this setting for themselves in the notification settings.
You can quickly see which comments involve you, because mentions for yourself (the user who is signed in) are highlighted in a different color.
Mentioning all members
Flag named disable_all_mention
introduced in GitLab 16.1. Disabled by default. Enabled on GitLab.com.
disable_all_mention
.
On GitLab.com, this flag is enabled.When this feature flag is enabled, typing @all
in comments and descriptions
results in plain text instead of a mention.
When you disable this feature, existing @all
mentions in the Markdown texts are not affected
and remain as links. Only future @all
mentions appear as plain text.
Avoid mentioning @all
in comments and descriptions.
When you do it, you don’t only mention the participants of the project, issue, or merge request,
but to all members of that project’s parent group.
All these users receive an email notification and a to-do item. It might be interpreted as spam.
Notifications and mentions can be disabled in a group’s settings.
Mention a group in an issue or merge request
When you mention a group in a comment, every member of the group gets a to-do item added to their To-do list.
- Open the MR or issue.
- In a comment, type
@
followed by the user, group, or subgroup namespace. For example,@alex
,@alex-team
, or@alex-team/marketing
. - Select Comment.
A to-do item is created for all the group and subgroup members.
Add a comment to a merge request diff
You can add comments to a merge request diff. These comments persist, even when you:
- Force-push after a rebase.
- Amend a commit.
To add a commit diff comment:
- To select a specific commit, on the merge request, select the Commits tab, select the commit message. To view the latest commit, select the Changes tab.
- By the line you want to comment on, hover over the line number and select Comment (). You can select multiple lines by dragging the Comment () icon.
- Enter your comment and select Start a review or Add comment now.
The comment is displayed on the merge request’s Overview tab.
The comment is not displayed on your project’s Code > Commits page.
28719b171a056960dfdc0012b625d0b47b123196
becomes 28719b17
that links to
https://gitlab.example.com/example-group/example-project/-/merge_requests/12345/diffs?commit_id=28719b171a056960dfdc0012b625d0b47b123196
.Reply to a comment by sending email
If you have “reply by email” configured, you can reply to comments by sending an email.
- When you reply to a standard comment, it creates another standard comment.
- When you reply to a threaded comment, it creates a reply in the thread.
- When you send an email to an issue email address, it creates a standard comment.
You can use Markdown and quick actions in your email replies.
Edit a comment
You can edit your own comment at any time. Anyone with at least the Maintainer role can also edit a comment made by someone else.
To edit a comment:
- On the comment, select Edit comment ().
- Make your edits.
- Select Save changes.
Editing a comment to add a mention
By default, when you mention a user, GitLab creates a to-do item for them, and sends them a notification email.
If you edit an existing comment to add a user mention that wasn’t there before, GitLab:
- Creates a to-do item for the mentioned user.
- Does not send a notification email.
Prevent comments by locking the discussion
You can prevent public comments in an issue or merge request. When you do, only project members can add and edit comments.
Prerequisite:
- In merge requests, you must have at least the Developer role.
- In issues, you must have at least the Reporter role.
To lock an issue or merge request:
- On the right sidebar, next to Lock issue or Lock merge request, select Edit.
- On the confirmation dialog, select Lock.
Notes are added to the page details.
If an issue or merge request is locked and closed, you cannot reopen it.
If you don’t see this action on the right sidebar, your project or instance might have moved sidebar actions enabled.
Add an internal note
-
Introduced in GitLab 13.9 with a flag named
confidential_notes
. Disabled by default. - Changed in GitLab 14.10: you can only mark comments in issues and epics as confidential. Previously, it was also possible for comments in merge requests and snippets.
- Renamed from “confidential comments” to “internal notes” in GitLab 15.0.
- Enabled on GitLab.com and self-managed in GitLab 15.0.
-
Feature flag
confidential_notes
removed in GitLab 15.2. - Changed permissions in GitLab 15.6 to at least the Reporter role. In GitLab 15.5 and earlier, issue or epic authors and assignees could also read and create internal notes.
You can add an internal note to an issue or an epic. It’s then visible only to project members who have at least the Reporter role.
Keep in mind:
- Replies to internal notes are also internal.
- You cannot turn an internal note into a regular comment.
Prerequisites:
- You must have at least the Reporter role for the project.
To add an internal note:
- Start adding a new comment.
- Below the comment, select the Make this an internal note checkbox.
- Select Add internal note.
You can also mark an issue as confidential.
Show only comments
In discussions with many comments, filter the discussion to show only comments or history of changes (system notes). System notes include changes to the description, mentions in other GitLab objects, or changes to labels, assignees, and the milestone. GitLab saves your preference, and applies it to every issue, merge request, or epic you view.
- Open the Overview tab in a merge request, issue, or epic.
- On the right side of the page, from the Sort or filter dropdown list, select a filter:
- Show all activity: Display all user comments and system notes.
- Show comments only: Display only user comments.
- Show history only: Display only activity notes.
Change activity sort order
Reverse the default order and interact with the activity feed sorted by most recent items at the top. GitLab saves your preference in local storage and applies it to every issue, merge request, or epic you view.
To change the activity sort order:
- Open the Overview tab in a merge request, issue, or epic.
- On the right side of the page, from the Sort or filter dropdown list, select the sort order Newest first or Oldest first (default).
View description change history
You can see changes to the description listed in the history.
To compare the changes, select Compare with previous version.
Assign an issue to the commenting user
You can assign an issue to a user who made a comment.
- In the comment, select the More Actions () menu.
- Select Assign to commenting user:
- To unassign the commenter, select the button again.
Create a thread by replying to a standard comment
When you reply to a standard comment, you create a thread.
Prerequisites:
- You must have at least the Guest role.
- You must be in an issue, merge request, or epic. Threads in commits and snippets are not supported.
To create a thread by replying to a comment:
-
In the upper-right corner of the comment, select Reply to comment ().
The reply section is displayed.
- Enter your reply.
- Select Reply or Add comment now (depending on where in the UI you are replying).
The top comment is converted to a thread.
Create a thread without replying to a comment
You can create a thread without replying to a standard comment.
Prerequisites:
- You must have at least the Guest role.
- You must be in an issue, merge request, commit, or snippet.
To create a thread:
- Enter a comment.
- Below the comment, to the right of Comment, select the down arrow ().
- From the list, select Start thread.
- Select Start thread again.
A threaded comment is created.
Resolve a thread
- Resolvable threads for issues introduced in GitLab 16.3 with a flag named
resolvable_issue_threads
. Disabled by default. - Resolvable threads for issues enabled on GitLab.com and self-managed in GitLab 16.4.
resolvable_issue_threads
.
On GitLab.com, this feature is available.You can resolve a thread when you want to finish a conversation.
Prerequisites:
- You must be in an issue or merge request.
- You must have at least the Developer role or be the author of the issue or merge request.
To resolve a thread:
- Go to the thread.
- Do one of the following:
- In the upper-right corner of the original comment, select Resolve thread ().
- Below the last reply, in the Reply field, select Resolve thread.
- Below the last reply, in the Reply field, enter text, select the Resolve thread checkbox, and select Add comment now.