<!--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=333883) </details> <!--IssueSummary end--> <!-- This issue template can be used a great starting point for feature requests. The last section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. --> ### 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). " --> When more than N commits are found in comparing the source and target branches, no title/description is pre-filled into the new merge request. ### Problem to solve <!-- What is the user problem you are trying to solve with this issue? --> Issue https://gitlab.com/gitlab-org/gitlab/-/issues/300479 changed the logic of how the default title and description works. Prior to it, if the compare of the selected source and target branches found more than a single commit, it will not pre-fill any values into the merge request form. Now, the implementation seeks out a multi-line commit in the compare commits result, and always attempts a pre-fill regardless of the count of commits found. For users with a workflow like the following, this has become an issue: 1. Two branches of work: `develop`, `master` (default branch) 1. Feature branches are made off of `develop` 1. The default `master` branch receives its changes from a different merge operation (from develop, or other tiered branches) 1. Feature MRs are created with the default target branch selection left unchanged (`master`) accidentally 1. Target branch is corrected to `develop` after the MR is created In step (4) due to the incorrect target branch selection the default title and description gets set to something entirely irrelevant as a result of seeking a multi-lined commit message, because the change history is very different between the feature branch (that came from `develop`) and `master` (the default branch). The MR gets created with a commit message that has little to do with the feature branch's actual commits. ### Proposal <!-- 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. --> We should continue to provide the older behavior as it felt more consistent. When seeking a multi-line commit to source the texts from, if the compare list is longer than 1 commit, we could limit the search to the latest 5 (or other small N) commits? Alternatively, we could go back to the previous behavior entirely and only fill when a single clear commit exists in the compare result, and leave blank for the user to fill in all other cases. This felt more intuitive/acceptable than seeing an incorrect commit message appear.