<!--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=442849) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal When using blame or looking at git history users are trying to understand what the change was and why was it made https://gitlab.com/gitlab-org/ux-research/-/issues/2920. But to get to this information requires many clicks to follow the path of commits (what changed) and eventually merge requests (to understand the why). Could there be a way to retrieve a list of commits and related merge requests to selected lines of code? This would eliminate the flow to follow "view past blame" https://gitlab.com/gitlab-org/ux-research/-/issues/2920#observations. With this list of commits viewing the changes of those lines over time is another goal of participants. This could have potential solutions as: - comparing specific files at different commit points (related to https://gitlab.com/gitlab-org/gitlab/-/issues/22245+), and/or - viewing the changes as a range diff (related to https://gitlab.com/gitlab-org/gitlab/-/issues/24096+) | Concept of line history | Concept of comparing files at different commit points | | ------ | ------ | |  |  | <!-- 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/ -->