Skip to content

Set default MR title/description to first multi-line commit

Max Coplan requested to merge vegerot/gitlab:300479-change-prefilled-mr-title-description into master

What does this MR do?

When creating a merge request, the behavior of the prefilled title and description is different than the behavior of squashed commit messages.

For squashed commit messages, the behavior is described in the docs as

The squashed commit’s commit message will be either:

  • Taken from the first multi-line commit message in the merge.
  • The merge request’s title if no multi-line commit message is found.

Example:

Let's say I make three commits like

commit 30542c9e21cd8ffa6f8b53702b4a4999f4b65332 (HEAD, gitlab/foo, develop)
Author: Max 🧙‍♂️ Coplan <mail@mail.com>
Date:   Fri Jan 29 16:30:21 2021 -0500

    feedback and testing

commit dcd270581872c76a8ff737e87a6013f017fcdfe7
Author: Max 🧙‍♂️ Coplan <mail@mail.coml>
Date:   Fri Jan 29 16:30:00 2021 -0500

    Closes WA-111 : short description

     ## Changelog

    - A thing
    - Another thing

    ----

commit 23b588519f9da0c69530583aa704fd051e71e9bc
Author: Max 🧙‍♂️ Coplan <mail@mail.coml>
Date:   Fri Jan 29 16:29:48 2021 -0500

    init

Then push it to gitlab like

❯ gp gitlab @:refs/heads/foo --force
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: To create a merge request for foo, visit:
remote:   https://mail.com/foo/bar/bar-app/-/merge_requests/new?merge_request%5Bsource_branch%5D=foo
remote:
To mail.com:foo/bar/bar-app.git
 + 834e04b1...30542c9e HEAD -> foo (forced update)

The current behavior would set the prefilled title to foo.

What is interesting about the current behavior is that GitLab's Merge Request documentation actually describes a different behavior. More details on this in the issue #300479 (closed) .

This commit makes the behavior consistent between squashed commits and prefilled MR title and description. This commit sets the prefilled MR title/description to the first multi-line commit in the MR, if applicable. Otherwise falling back to the previous behavior.

Screenshots (strongly suggested)

The new title and description, screenshot taken from this branch: image

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Fixes #300479 (closed)

Questions for reviewer

  • I am having trouble adding :gitaly_commit? to the RSPec double object. Assistance with that would be appreciated! 🙂 (thanks @ck3g !!!)

  • How do we think we should handle the case of a multi-line commit message, when the source branch matches an issue?

    • For this question, I think the test cases really help explain the problem

If a user has a multi-line commit like

Resolve #1234: add feature

This commit adds the feature to the thing

and they are on the branch 1234-abcd

What should the prefilled MR title be?

This is a genuine question that I think comes down to preference.

imo if they took the TIME to write a multi-line commit message, then that probably signals their intent that it is important and should be read by others.

Therefor I think the MR title should be

Resolve #1234: add feature

and the description

This commit adds the feature to the thing

But I could also see someone expecting the title to be

Resolve abcd

.

Something I would like to reiterate is that none of this is set in stone. The user may set their title and description to whatever they'd like before opening the MR. But this MR just tries to be a bit more helpful for what it suggests for those.

We can all agree that

first commit
nil

Is not as helpful as

Resolve #1234: add feature
This commit adds the feature to the thing

But the user is free to make it whatever they want.

Again, my intuition says if they go through the effort to write a multiline commit message, it is more helpful to use that as the MR title and description than NO description

Edited by Max Coplan

Merge request reports