[go: up one dir, main page]

Skip to content

Refine behavior of merge request's default title/descriptions

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

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

Issue #300479 (closed) 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)
  2. Feature branches are made off of develop
  3. The default master branch receives its changes from a different merge operation (from develop, or other tiered branches)
  4. Feature MRs are created with the default target branch selection left unchanged (master) accidentally
  5. 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

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.

Edited by 🤖 GitLab Bot 🤖