Provide a quick way to display Last MRs that changed a certain file from within the blob view page
<!--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=393920) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Context While investigating regressions, an engineer usually identifies the file(s) that have the broken behaviour. An important piece of the puzzle to answer: "This was working 2 days ago, why did it break now?" is checking recent changes to that file. Usually that revolves around pulling up the History to see the commits in that file. However, depending on the merge strategy this can include varying levels of noise. Merge Requests carry entire units of change, contextualised to what change was actually being shipped. So what if while viewing a Blob page... we could quickly see which MRs have recently touched this file? :thinking: ### Proposal * Add a button/link: "Recent MRs" to the blob page * Upon clicking, it would display a list of MRs in chronological order from newest to oldest. Note: it could be similar to how we plan to reveal the tags and MRs on commit details page. <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> ### Questions * Is this a valid "shortcut" that saves times for our users? * Can we do this lookup performantly on the backend? * Should we do this for every branch in the repo? * ...
issue