### Summary I clicked on the "version 4 of the diff" link in a merge request I was reviewing https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26149 and was brought to a page with a gigantic diff that was completely unrelated to the merge request. ### Steps to reproduce 1) Visit this particular MR comment thread: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26149#note_297765397 2) Click on "version 4 of the diff" ### Example Project It's happening on the gitlab project, on gitlab.com. ### What is the current *bug* behavior? A massive diff is rendered, across 902 files. ### What is the expected *correct* behavior? A much smaller diff should be rendered, for the MR author's specific push to the open MR. The diff should be a subset of the current MR diff. ### Relevant logs and/or screenshots #### The actual MR, with +46/-30 lines across 13 files in 2 commits:  #### The target of the diff link:  #### The diff stats on the linked page:  ### Output of checks This bug happens on GitLab.com ### Possible fixes I believe that we're selecting a very old commit to compare with a merged results pipeline, probably the git most-recent-common-commit, by [using triple-dot in the diff logic](https://stackoverflow.com/questions/7251477/what-are-the-differences-between-double-dot-and-triple-dot-in-git-dif). If we're using pipelines for merged results, we should be comparing the MR head commit to the direct parent of the merge commit from the target branch, not the one way back where the source branch diverged from the target. I've written a much more extensive explanation, with accompanying diagrams, of the implementation problem in https://gitlab.com/gitlab-org/gitlab/-/issues/238399+