<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### 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). " --> Introduce `git show --find-renames` functionality to show MR diffs for moved-and-changed files nicely. ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> I have MR consisting of [two commits](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/412/commits): - [first commit](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/412/diffs?commit_id=dd11c429a735b6670e9ddf3a8146c1a2b80ec171) just moves the file mostly (and it looks good) - [second commit](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/412/diffs?commit_id=3103fce1f0b4def07b66cae1fe4e5f21a475933e) does actual changes to the files (it also looks OK) The problem is - I and other reviewers can't see actual changes for the moved file in the [whole MR](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/412/diffs): instead, it looks like if the old file was [deleted](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/412/diffs#diff-content-bacf705603ca021e20f768fce8e73057a77a42f6) and then new one is [added](https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/412/diffs#diff-content-511fa9871a57f948afb9032371d52025455c3572) ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> * [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) ### User experience goal <!-- What is the single user experience workflow this problem addresses? For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>" https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ --> The user should be able to use the UI with GitLab to set a threshold on the similarity index (i.e. amount of addition/deletions compared to the file’s size) to achieve proper MR representation. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> Implement UI for Git's `show/diff --find-renames` option: > _**-M[\<n>], --find-renames[=\<n>]**_ > If generating diffs, detect and report renames for each commit. For following files across renames while traversing history, see --follow. If n is specified, it is a threshold on the similarity index (i.e. amount of addition/deletions compared to the file’s size). For example, -M90% means Git should consider a delete/add pair to be a rename if more than 90% of the file hasn’t changed. Without a % sign, the number is to be read as a fraction, with a decimal point before it. I.e., -M5 becomes 0.5, and is thus the same as -M50%. Similarly, -M05 is the same as -M5%. To limit detection to exact renames, use -M100%. The default similarity index is 50%. For example, the MR above shows good result with the following command: `git show -M15%` ### Further details <!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. --> ### Links / references https://gitlab.com/gitlab-org/gitlab-foss/-/issues/42314 https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17091 <!-- Label reminders - you should have one of each of the following labels. Read the descriptions on https://gitlab.com/gitlab-org/gitlab/-/labels to find the correct ones -->