• Where you can create comments
• Reply to a comment by sending email
• Who can edit comments
• Resolvable comments and threads
  • Commit threads in the context of a merge request
  • Marking a comment or thread as resolved
  • Move all unresolved threads in a merge request to an issue
  • Moving a single thread to a new issue
  • Only allow merge requests to be merged if all threads are resolved
  • Automatically resolve merge request diff threads when they become outdated
• Commit threads
• Threaded discussions
• Image threads
• Lock discussions
• Confidential Comments
• Filtering notes
• Start a thread by replying to a standard comment
• Assign an issue to the commenting user
• Enable or disable Confidential Comments

Comments and threads

GitLab encourages communication through comments, threads, and code suggestions.

There are two types of comments:

• A standard comment.
• A comment in a thread, which has to 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.

Where you can create comments

You can create comments in places like:

• Commit diffs
• Commits
• Designs
• Epics
• Issues
• Merge requests
• Snippets

Each object can have as many as 5,000 comments.

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, another standard comment is created.
• When you reply to a threaded comment, it creates a reply in the thread.

You can use Markdown and quick actions in your email replies.

Who can edit comments

You can edit your own comment at any time.

Anyone with the Maintainer role or higher can also edit a comment made by someone else.

Resolvable comments and threads

Thread resolution helps keep track of progress during planning or code review.

Every thread in merge requests, commits, commit diffs, and snippets is initially displayed as unresolved. They can then be individually resolved by anyone with at least Developer access to the project or by the author of the change being reviewed. If the thread has been resolved and a non-member un-resolves their own response, this also unresolves the discussion thread. If the non-member then resolves this same response, this resolves the discussion thread.

The need to resolve threads prevents you from forgetting to address feedback and lets you hide threads that are no longer relevant.

Commit threads in the context of a merge request

For reviewers with commit-based workflow, it may be useful to add threads to specific commit diffs in the context of a merge request. These threads persist through a commit ID change when:

• force-pushing after a rebase
• amending a commit

To create a commit diff thread:

1. Navigate to the merge request Commits tab. A list of commits that constitute the merge request are shown.

   

2. Navigate to a specific commit, select the Changes tab (where you are only be presented diffs from the selected commit), and leave a comment.

   

3. Any threads created this way are shown in the merge request’s Discussions tab and are resolvable.

   

Threads created this way only appear in the original merge request and not when navigating to that commit under your project’s Repository > Commits page.

Marking a comment or thread as resolved

You can mark a thread as resolved by selecting the Resolve thread button at the bottom of the thread.

Alternatively, you can mark each comment as resolved individually.

Move all unresolved threads in a merge request to an issue

To continue all open threads from a merge request in a new issue, select Resolve all threads in new issue.

Alternatively, when your project only accepts merge requests when all threads are resolved, an open an issue to resolve them later link displays in the merge request widget.

This prepares an issue with its content referring to the merge request and the unresolved threads.

Hitting Create issue causes all threads to be marked as resolved and add a note referring to the newly created issue.

You can now proceed to merge the merge request from the UI.

Moving a single thread to a new issue

To create a new issue for a single thread, you can use the Resolve this thread in a new issue button.

This directs you to a new issue prefilled with the content of the thread, similar to the issues created for delegating multiple threads at once. Saving the issue marks the thread as resolved and add a note to the merge request thread referencing the new issue.

Only allow merge requests to be merged if all threads are resolved

You can prevent merge requests from being merged until all threads are resolved.

Navigate to your project’s settings page, select the Only allow merge requests to be merged if all threads are resolved check box and hit Save for the changes to take effect.

From now on, you can’t merge from the UI until all threads are resolved.

Automatically resolve merge request diff threads when they become outdated

You can automatically resolve merge request diff threads on lines modified with a new push.

Navigate to your project’s settings page, select the Automatically resolve merge request diffs threads on lines changed with a push check box and hit Save for the changes to take effect.

From now on, any threads on a diff are resolved by default if a push makes that diff section outdated. Threads on lines that don’t change and top-level resolvable threads are not automatically resolved.

Commit threads

You can add comments and threads to a particular commit under your project’s Repository > Commits.

Threaded discussions

While resolvable threads are only available to merge request diffs, threads can also be added without a diff. You can start a specific thread which looks like a thread, on issues, commits, snippets, and merge requests.

To start a threaded discussion, select the Comment button toggle dropdown, select Start thread, and then select Start thread when you’re ready to post the comment.

This posts a comment with a single thread to allow you to discuss specific comments in greater detail.

Image threads

Sometimes a thread is revolved around an image. With image threads, you can easily target a specific coordinate of an image and start a thread around it. Image threads are available in merge requests and commit detail views.

To start an image thread, hover your mouse over the image. Your mouse pointer should convert into an icon, indicating that the image is available for commenting. Simply click anywhere on the image to create a new thread.

After you select the image, a comment form is displayed that would be the start of your thread. After you save your comment, a new badge is displayed on top of your image. This badge represents your thread.

Image threads also work on diffs that replace an existing image. In this diff view mode, you can toggle the different view modes and still see the thread point badges.

2-up	Swipe	Onion Skin

Image threads also work well with resolvable threads. Resolved threads on diffs (not on the merge request discussion tab) appear collapsed on page load and have a corresponding badge counter to match the counter on the image.

Lock discussions

For large projects with many contributors, it may be useful to stop threads in issues or merge requests in these scenarios:

• The project maintainer has already resolved the thread and it is not helpful for continued feedback.
• The project maintainer has already directed new conversation to newer issues or merge requests.
• The people participating in the thread are trolling, abusive, or otherwise being unproductive.

In these cases, a user with Developer permissions or higher in the project can lock (and unlock) an issue or a merge request, using the “Lock” section in the sidebar. For issues, a user with Reporter permissions can lock (and unlock).

Unlock	Lock

System notes indicate locking and unlocking.

In a locked issue or merge request, only team members can add new comments and edit existing comments. Non-team members are restricted from adding or editing comments.

Team member	Non-team member

Additionally, locked issues and merge requests can’t be reopened.

Confidential Comments

When creating a comment, you can make it visible only to the project members (users with Reporter and higher permissions).

To create a confidential comment, select the Make this comment confidential check box before you submit it.

Filtering notes

For issues with many comments like activity notes and user comments, sometimes finding useful information can be hard. There is a way to filter comments from single notes and threads for merge requests and issues.

From a merge request’s Discussion tab, or from an epic/issue overview, find the filter’s dropdown menu on the right side of the page, from which you can choose one of the following options:

• Show all activity: displays all user comments and system notes (issue updates, mentions from other issues, changes to the description, etc).
• Show comments only: only displays user comments in the list.
• Show history only: only displays activity notes.

After you select one of the filters in a given issue or merge request, GitLab saves your preference, so that it persists when you visit the same page again from any device you’re logged into.

Start a thread by replying to a standard comment

To reply to a standard (non-thread) comment, you can use the Reply to comment button.

The Reply to comment button is only displayed if you have permissions to reply to an existing thread, or start a thread from a standard comment.

Selecting the Reply to comment button brings the reply area into focus and you can type your reply.

Replying to a non-thread comment converts the non-thread comment to a thread after the reply is submitted. This conversion is considered an edit to the original comment, so a note about when it was last edited appears underneath it.

This feature exists only for issues, merge requests, and epics. Commits, snippets, and merge request diff threads are not supported yet.

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, and then select Assign to commenting user.

Select the button again to unassign the commenter.

Enable or disable Confidential Comments

Confidential Comments is under development and not ready for production use. It is deployed behind a feature flag that is disabled by default. GitLab administrators with access to the GitLab Rails console can enable it.

To enable it:

Feature.enable(:confidential_notes)

To disable it:

Feature.disable(:confidential_notes)