<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=363869) </details> <!--IssueSummary end--> <!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> Add an option to hide changes introduced by merges from target to source. ### Problem to solve Suppose the following workflow: * Commit changes (A) to feature1 * Create MR feature1->master * Review all changes * Commit changes (M) on master (e.g. by another MR) * Merge master -> feature1 (e.g. motivated by a merge conflict) * Add more commits (B) to feature1 As a reviewer, I want to see only changes with the following properties: * not already available in target/master * not reviewed yet / introduced to feature1 after my previous review of A. Currently, there are only two options available to the reviewer: * Diff master->latest. This will require re-review of changes in A. * Diff version1/A->latest. This will show all changes introduced to master, which have already been reviewed by someone else during the corresponding MR. Depending on activity on master, this will blow up the review with hundreds of unrelated changes. ### Proposal Add an option to hide changes introduced by merges from the target branch. #### Option 1 Show a "combined diff" for merge commits. Such a diff can be obtained on the command line by issuing `git show $MERGECOMMIT`. It may make sense to split off the merge into a separate review-version for this. This is the cleaner option, but would require the diff-view to be able to display combined diffs. #### Option 2 Alternatively, it would be possible to filter on the file level and at least exclude all files that would not be changed by the MR. This would also show other changes in the same file, which will still be a lot of noise. But at least, completely unrelated changes to other files would be hidden. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Feature Usage Metrics ### Further notes Opening this ticket was suggested in https://support.gitlab.com/hc/en-us/requests/291926