<!--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=506474) </details> <!--IssueSummary end--> The following discussion from !173382 should be addressed: - [ ] @patrickbajao started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173382#note_2227644574): (+2 comments) > I was thinking about this more today and I feel that it's better to have a controller concern something like `WithMergeRequestCommit` and we move the `#commit` method there. We can then include this concern in both `MergeRequestsController` and `DiffsController`. It would look something like: > > > ```ruby > module WithMergeRequestCommit > def commit > commit_id = params[:commit_id].presence > return unless commit_id > > return unless @merge_request.all_commits.exists?(sha: commit_id) || > @merge_request.recent_context_commits.map(&:id).include?(commit_id) > > @commit ||= @project.commit(commit_id) > end > end > > class DiffsController > include WithMergeRequestCommit > end > > class MergeRequestsController > include WithMergeRequestCommit > end > ``` > > Doing it this way means if a controller needs the `#commit` method they can include the concern. Compared to what we have now wherein all controllers inheriting from `MergeRequests::ApplicationController` have access to `#commit` even if they don't need it, I think it's better.