Commit 46c8347a authored by Craig Norris's avatar Craig Norris

Merge branch '327754-aqualls-reviews-page' into 'master'

Continue untangling Threads and Reviews pages

See merge request gitlab-org/gitlab!60965
parents e6200998 08166c1e
......@@ -9,7 +9,7 @@ type: reference
You can set a maximum size for display of diff files (patches).
For details about diff files, [View changes between files](../project/merge_requests/reviews/index.md#view-changes-between-file-versions).
For details about diff files, [view changes between files](../project/merge_requests/changes.md).
## Maximum diff patch size
......@@ -23,10 +23,10 @@ This affects merge requests and branch comparison views.
To set the maximum diff patch size:
1. Go to **Admin Area > Settings > General**.
1. Go to the Admin Area (**{admin}**) and select **Settings > General**.
1. Expand **Diff limits**.
1. Enter a value for **Maximum diff patch size**, measured in bytes.
1. Click on **Save changes**.
1. Select **Save changes**.
WARNING:
This setting is experimental. An increased maximum increases resource
......
......@@ -91,7 +91,7 @@ current merge request.
### Marking a comment or thread as resolved
You can mark a thread as resolved by clicking the **Resolve thread**
You can mark a thread as resolved by selecting the **Resolve thread**
button at the bottom of the thread.
!["Resolve thread" button](img/resolve_thread_button_v13_3.png)
......@@ -102,8 +102,8 @@ 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, click the
**Resolve all threads in new issue** button.
To continue all open threads from a merge request in a new issue, select
**Resolve all threads in new issue**.
![Open new issue for all unresolved threads](img/btn_new_issue_for_all_threads.png)
......@@ -283,85 +283,6 @@ To create a confidential comment, select the **Make this comment confidential**
![Confidential comments](img/confidential_comments_v13_9.png)
## Merge request reviews
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4213) in GitLab Premium 11.4.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/28154) to GitLab Free in 13.1.
When looking at a merge request diff, you are able to start a review.
This allows you to create comments inside a merge request that are **only visible to you** until published,
in order to allow you to submit them all as a single action.
### Starting a review
To start a review, write a comment on a diff as normal under the **Changes** tab
in a merge request, and then select **Start a review**.
![Starting a review](img/mr_review_start.png)
After a review is started, any comments that are part of this review are marked `Pending`.
All comments that are part of a review show two buttons:
- **Finish review**: Submits all comments that are part of the review, making them visible to other users.
- **Add comment now**: Submits the specific comment as a regular comment instead of as part of the review.
![A comment that is part of a review](img/pending_review_comment.png)
You can use [quick actions](../project/quick_actions.md) inside review comments. The comment shows the actions to perform after publication.
![A review comment with quick actions](img/review_comment_quickactions.png)
To add more comments to a review, start writing a comment as normal and click the **Add to review** button.
![Adding a second comment to a review](img/mr_review_second_comment.png)
This adds the comment to the review.
![Second review comment](img/mr_review_second_comment_added.png)
### Resolving/Unresolving threads
Review comments can also resolve/unresolve [resolvable threads](#resolvable-comments-and-threads).
When replying to a comment, a checkbox is displayed that you can click to resolve or unresolve
the thread after publication.
![Resolve checkbox](img/mr_review_resolve.png)
If a particular pending comment resolves or unresolves the thread, this is shown on the pending
comment itself.
![Resolve status](img/mr_review_resolve2.png)
![Unresolve status](img/mr_review_unresolve.png)
### Adding a new comment
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8225) in GitLab 13.10.
If you have a review in progress, you will be presented with the option to **Add to review**:
![New thread](img/mr_review_new_comment_v13_11.png)
### Submitting a review
If you have any comments that have not been submitted, a bar displays at the
bottom of the screen with two buttons:
- **Pending comments**: Opens a list of comments ready to be submitted for review.
- **Submit review**: Publishes all comments. Any quick actions submitted are performed at this time.
Alternatively, to finish the entire review from a pending comment:
- Click the **Submit review** button on the comment.
- Use the `/submit_review` [quick action](../project/quick_actions.md) in the text of non-review comment.
![Review submission](img/review_preview_v13_11.png)
Submitting the review sends a single email to every notifiable user of the
merge request with all the comments associated to it.
Replying to this email will, consequentially, create a new comment on the associated merge request.
## Filtering notes
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/26723) in GitLab 11.5.
......@@ -392,7 +313,7 @@ To reply to a standard (non-thread) comment, you can use the **Reply to comment*
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.
Clicking on the **Reply to comment** button brings the reply area into focus and you can type your reply.
Selecting the **Reply to comment** button brings the reply area into focus and you can type your reply.
![Reply to comment feature](img/reply_to_comment.gif)
......@@ -409,9 +330,9 @@ not supported yet.
You can assign an issue to a user who made a comment.
In the comment, click the **More Actions** menu and click **Assign to commenting user**.
In the comment, select the **More Actions** menu, and then select **Assign to commenting user**.
Click the button again to unassign the commenter.
Select the button again to unassign the commenter.
![Assign to commenting user](img/quickly_assign_commenter_v13_1.png)
......
---
stage: Create
group: Code Review
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
type: index, reference
---
# Changes tab in merge requests
The **Changes** tab on a [merge request](index.md), below the main merge request details and next to the discussion tab,
shows the changes to files between branches or commits. This view of changes to a
file is also known as a **diff**. By default, the diff view compares the file in the
merge request branch and the file in the target branch.
The diff view includes the following:
- The file's name and path.
- The number of lines added and deleted.
- Buttons for the following options:
- Toggle comments for this file; useful for inline reviews.
- Edit the file in the merge request's branch.
- Show full file, in case you want to look at the changes in context with the rest of the file.
- View file at the current commit.
- Preview the changes with [Review Apps](../../../ci/review_apps/index.md).
- The changed lines, with the specific changes highlighted.
![Example screenshot of a source code diff](img/merge_request_diff_v12_2.png)
## Merge request diff file navigation
When reviewing changes in the **Changes** tab, the diff can be navigated using
the file tree or file list. As you scroll through large diffs with many
changes, you can quickly jump to any changed file using the file tree or file
list.
![Merge request diff file navigation](img/merge_request_diff_file_navigation.png)
## Collapsed files in the Changes view
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/232820) in GitLab 13.4.
When you review changes in the **Changes** tab, files with a large number of changes are collapsed
to improve performance. When files are collapsed, a warning appears at the top of the changes.
Select **Expand file** on any file to view the changes for that file.
## File-by-file diff navigation
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222790) in GitLab 13.2.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/229848) in GitLab 13.7.
For larger merge requests, consider reviewing one file at a time. To enable this feature:
1. In the top-right corner, select your avatar.
1. Select **Preferences**.
1. Scroll to the **Behavior** section and select **Show one file at a time on merge request's Changes tab**.
1. Select **Save changes**.
After you enable this setting, GitLab displays only one file at a time in the **Changes** tab when you review merge requests. You can select **Prev** and **Next** to view other changed files.
![File-by-file diff navigation](img/file_by_file_v13_2.png)
In [GitLab 13.7](https://gitlab.com/gitlab-org/gitlab/-/issues/233898) and later, if you want to change
this behavior, you can do so from your **User preferences** (as explained above) or directly in a
merge request:
1. Go to the merge request's **Changes** tab.
1. Select the cog icon (**{settings}**) to reveal the merge request's settings dropdown.
1. Select or clear the checkbox **Show one file at a time** to change the setting accordingly.
This change overrides the choice you made in your user preferences and persists until you clear your
browser's cookies or change this behavior again.
## Merge requests commit navigation
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18140) in GitLab 13.0.
To seamlessly navigate among commits in a merge request:
1. Select the **Commits** tab.
1. Select a commit to open it in the single-commit view.
1. Navigate through the commits by either:
- Selecting **Prev** and **Next** buttons below the tab buttons.
- Using the <kbd>X</kbd> and <kbd>C</kbd> keyboard shortcuts.
![Merge requests commit navigation](img/commit_nav_v13_11.png)
## Incrementally expand merge request diffs
By default, the diff shows only the parts of a file which are changed.
To view more unchanged lines above or below a change select the
**Expand up** or **Expand down** icons. You can also select **Show unchanged lines**
to expand the entire file.
![Incrementally expand merge request diffs](img/incrementally_expand_merge_request_diffs_v12_2.png)
In GitLab [versions 13.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/205401), when viewing a
merge request's **Changes** tab, if a certain file was only renamed, you can expand it to see the
entire content by selecting **Show file contents**.
## Ignore whitespace changes in Merge Request diff view
If you select the **Hide whitespace changes** button, you can see the diff
without whitespace changes (if there are any). This is also working when on a
specific commit page.
![MR diff](img/merge_request_diff.png)
NOTE:
You can append `?w=1` while on the diffs page of a merge request to ignore any
whitespace changes.
## Mark files as viewed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51513) in GitLab 13.9.
> - Deployed behind a feature flag, enabled by default.
> - Enabled on GitLab.com.
> - Recommended for production use.
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-file-views). **(FREE SELF)**
When reviewing a merge request with many files multiple times, it may be useful to the reviewer
to focus on new changes and ignore the files that they have already reviewed and don't want to
see anymore unless they are changed again.
To mark a file as viewed:
1. Go to the merge request's **Diffs** tab.
1. On the right-top of the file, locate the **Viewed** checkbox.
1. Select it to mark the file as viewed.
Once checked, the file remains marked for that reviewer unless there are newly introduced
changes to its content or the checkbox is unchecked.
### Enable or disable file views **(FREE SELF)**
The file view feature is under development but ready for production use.
It is deployed behind a feature flag that is **enabled by default**.
[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
can opt to enable it for your instance.
To enable it:
```ruby
Feature.enable(:local_file_reviews)
```
To disable it:
```ruby
Feature.disable(:local_file_reviews)
```
......@@ -70,7 +70,7 @@ After you have created the merge request, you can also:
- Preview continuous integration [pipelines on the merge request widget](reviews/index.md#pipeline-status-in-merge-requests-widgets).
- Preview how your changes look directly on your deployed application with [Review Apps](reviews/index.md#live-preview-with-review-apps).
- [Allow collaboration on merge requests across forks](allow_collaboration.md).
- Perform a [Review](../../discussions/index.md#merge-request-reviews) to create multiple comments on a diff and publish them when you're ready.
- Perform a [Review](reviews/index.md) to create multiple comments on a diff and publish them when you're ready.
- Add [code suggestions](reviews/suggestions.md) to change the content of merge requests directly into merge request threads, and easily apply them to the codebase directly from the UI.
- Add a time estimation and the time spent with that merge request with [Time Tracking](../time_tracking.md#time-tracking).
......
......@@ -8,7 +8,6 @@ type: index, reference
# Merge requests **(FREE)**
Merge requests (MRs) are the way you check source code changes into a branch.
When you open a merge request, you can visualize and collaborate on the code changes before merge.
Merge requests include:
......@@ -18,6 +17,11 @@ Merge requests include:
- A comment section for discussion threads.
- The list of commits.
Merge requests contain tabs at the top of the page to help you navigate to
important parts of the merge request: **Overview**, **Commits**, **Pipelines**, and **Changes**.
![Merge request tab positions](img/merge_request_tab_position_v13_11.png)
To get started, read the [introduction to merge requests](getting_started.md).
## Merge request workflows
......@@ -47,28 +51,6 @@ For a web developer writing a webpage for your company's website:
1. Once approved, your merge request is [squashed and merged](squash_and_merge.md), and [deployed to staging with GitLab Pages](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/).
1. Your production team [cherry picks](cherry_pick_changes.md) the merge commit into production.
## Merge request navigation tabs at the top
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33813) in GitLab 12.6. This positioning is experimental.
In GitLab 12.5 and earlier, navigation tabs in merge requests (**Discussion**,
**Commits**, **Pipelines**, and **Changes**) were located after the merge request
widget.
To facilitate navigation without scrolling, and based on user feedback, the tabs are
now located at the top of the merge request tab. A new **Overview** tab was added,
and next to **Overview** are **Commits**, **Pipelines**, and **Changes**.
![Merge request tab positions](img/merge_request_tab_position_v13_11.png)
This change is behind a feature flag that is enabled by default. For
self-managed instances, it can be disabled through the Rails console by a GitLab
administrator with the following command:
```ruby
Feature.disable(:mr_tabs_position)
```
## Related topics
- [Create a merge request](creating_merge_requests.md)
......
......@@ -5,21 +5,19 @@ info: To determine the technical writer assigned to the Stage/Group associated w
type: index, reference
---
# Suggest Changes
# Suggest changes **(FREE)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/18008) in GitLab 11.6.
> - Custom commit messages for suggestions was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25381) in GitLab 13.9 behind a [feature flag](../../../feature_flags.md), disabled by default.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/297404) in GitLab 13.10.
As a reviewer, you're able to suggest code changes with a
Markdown syntax in merge request diff threads. Then, the
merge request author (or other users with appropriate
[permission](../../../permissions.md)) is able to apply these
Suggestions with a click, which generates a commit in
the merge request authored by the user that applied them.
As a reviewer, you're able to suggest code changes with a Markdown syntax in merge request
diff threads. Then, the merge request author (or other users with appropriate
[permission](../../../permissions.md)) is able to apply these suggestions with a click,
which generates a commit in the merge request authored by the user that applied them.
1. Choose a line of code to be changed, add a new comment, then click
on the **Insert suggestion** icon in the toolbar:
1. Choose a line of code to be changed, add a new comment, then select
the **Insert suggestion** icon in the toolbar:
![Add a new comment](img/suggestion_button_v13_9.png)
......@@ -27,9 +25,10 @@ the merge request authored by the user that applied them.
![Add a suggestion into a code block tagged properly](img/make_suggestion_v13_9.png)
1. Click either **Start a review** or **Add to review** to add your comment to a [review](index.md), or **Add comment now** to add the comment to the thread immediately.
1. Select either **Start a review** or **Add to review** to add your comment to a
[review](index.md), or **Add comment now** to add the comment to the thread immediately.
The Suggestion in the comment can be applied by the merge request author
The suggestion in the comment can be applied by the merge request author
directly from the merge request:
![Apply suggestions](img/apply_suggestion_v13_9.png)
......@@ -40,34 +39,34 @@ the merge request authored by the user that applied them.
![Custom commit](img/custom_commit_v13_9.png)
After the author applies a Suggestion, it is marked with the **Applied** label,
After the author applies a suggestion, it's marked with the **Applied** label,
the thread is automatically resolved, and GitLab creates a new commit
and push the suggested change directly into the codebase in the merge request's
and pushes the suggested change directly into the codebase in the merge request's
branch. [Developer permission](../../../permissions.md) is required to do so.
## Multi-line Suggestions
## Multi-line suggestions
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53310) in GitLab 11.10.
Reviewers can also suggest changes to multiple lines with a single Suggestion
Reviewers can also suggest changes to multiple lines with a single suggestion
within merge request diff threads by adjusting the range offsets. The
offsets are relative to the position of the diff thread, and specify the
range to be replaced by the suggestion when it is applied.
![Multi-line suggestion syntax](img/multi-line-suggestion-syntax.png)
In the example above, the Suggestion covers three lines above and four lines
In the previous example, the suggestion covers three lines above and four lines
below the commented line. When applied, it would replace from 3 lines _above_
to 4 lines _below_ the commented line, with the suggested change.
![Multi-line suggestion preview](img/multi-line-suggestion-preview.png)
NOTE:
Suggestions covering multiple lines are limited to 100 lines _above_ and 100
lines _below_ the commented diff line, allowing up to 200 changed lines per
Suggestions for multiple lines are limited to 100 lines _above_ and 100
lines _below_ the commented diff line. This allows for up to 200 changed lines per
suggestion.
## Code block nested in Suggestions
## Code block nested in suggestions
If you need to make a suggestion that involves a
[fenced code block](../../../markdown.md#code-spans-and-blocks), wrap your suggestion in four backticks
......@@ -77,43 +76,44 @@ instead of the usual three.
![Output of a comment with a suggestion with a fenced code block](img/suggestion_code_block_output_v12_8.png)
## Configure the commit message for applied Suggestions
## Configure the commit message for applied suggestions
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13086) in GitLab 12.7.
GitLab uses a default commit message
when applying Suggestions: `Apply %{suggestions_count} suggestion(s) to %{files_count} file(s)`
when applying suggestions: `Apply %{suggestions_count} suggestion(s) to %{files_count} file(s)`
For example, consider that a user applied 3 suggestions to 2 different files, the default commit message is: **Apply 3 suggestion(s) to 2 file(s)**
For example, consider that a user applied 3 suggestions to 2 different files, the
default commit message is: **Apply 3 suggestion(s) to 2 file(s)**
These commit messages can be customized to follow any guidelines you might have. To do so, expand the **Merge requests**
tab within your project's **General** settings and change the
**Merge suggestions** text:
These commit messages can be customized to follow any guidelines you might have.
To do so, expand the **Merge requests** tab within your project's **General**
settings and change the **Merge suggestions** text:
![Custom commit message for applied Suggestions](img/suggestions_custom_commit_messages_v13_1.jpg)
![Custom commit message for applied suggestions](img/suggestions_custom_commit_messages_v13_1.jpg)
You can also use following variables besides static text:
| Variable | Description | Output example |
|------------------------|-------------|----------------|
| `%{branch_name}` | The name of the branch the Suggestion(s) was(were) applied to. | `my-feature-branch` |
| `%{files_count}` | The number of file(s) to which Suggestion(s) was(were) applied.| **2** |
| `%{file_paths}` | The path(s) of the file(s) Suggestion(s) was(were) applied to. Paths are separated by commas.| `docs/index.md, docs/about.md` |
| `%{branch_name}` | The name of the branch the suggestion(s) was(were) applied to. | `my-feature-branch` |
| `%{files_count}` | The number of file(s) to which suggestion(s) was(were) applied.| **2** |
| `%{file_paths}` | The path(s) of the file(s) suggestion(s) was(were) applied to. Paths are separated by commas.| `docs/index.md, docs/about.md` |
| `%{project_path}` | The project path. | `my-group/my-project` |
| `%{project_name}` | The human-readable name of the project. | **My Project** |
| `%{suggestions_count}` | The number of Suggestions applied.| **3** |
| `%{username}` | The username of the user applying Suggestion(s). | `user_1` |
| `%{user_full_name}` | The full name of the user applying Suggestion(s). | **User 1** |
| `%{suggestions_count}` | The number of suggestions applied.| **3** |
| `%{username}` | The username of the user applying suggestion(s). | `user_1` |
| `%{user_full_name}` | The full name of the user applying suggestion(s). | **User 1** |
For example, to customize the commit message to output
**Addresses user_1's review**, set the custom text to
`Addresses %{username}'s review`.
NOTE:
Custom commit messages for each applied Suggestion is
Custom commit messages for each applied suggestion is
introduced by [#25381](https://gitlab.com/gitlab-org/gitlab/-/issues/25381).
## Batch Suggestions
## Batch suggestions
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25486) in GitLab 13.1 as an [alpha feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#alpha) behind a feature flag, disabled by default.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/227799) in GitLab 13.2.
......@@ -122,7 +122,7 @@ introduced by [#25381](https://gitlab.com/gitlab-org/gitlab/-/issues/25381).
You can apply multiple suggestions at once to reduce the number of commits added
to your branch to address your reviewers' requests.
1. To start a batch of suggestions to apply with a single commit, click **Add suggestion to batch**:
1. To start a batch of suggestions to apply with a single commit, select **Add suggestion to batch**:
![A code change suggestion displayed, with the button to add the suggestion to a batch highlighted.](img/add_first_suggestion_to_batch_v13_1.jpg "Add a suggestion to a batch")
......@@ -130,11 +130,11 @@ to your branch to address your reviewers' requests.
![A code change suggestion displayed, with the button to add an additional suggestion to a batch highlighted.](img/add_another_suggestion_to_batch_v13_1.jpg "Add another suggestion to a batch")
1. To remove suggestions, click **Remove from batch**:
1. To remove suggestions, select **Remove from batch**:
![A code change suggestion displayed, with the button to remove that suggestion from its batch highlighted.](img/remove_suggestion_from_batch_v13_1.jpg "Remove a suggestion from a batch")
1. Having added all the suggestions to your liking, when ready, click **Apply suggestions**:
1. Having added all the suggestions to your liking, when ready, select **Apply suggestions**:
![A code change suggestion displayed, with the button to apply the batch of suggestions highlighted.](img/apply_batch_of_suggestions_v13_1.jpg "Apply a batch of suggestions")
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment