Squash and merge is currently destructive with respect to commit messages, squashing all the changes with a commit message of the merge request title. This is rarely a useful message, and is duplicative of the merge commit content (when not using fast forward only merge strategy). We should not only make it easy to add good commit messages if a user forgets, but be suggestive by making the commit message more obvious, and celebrate good commit messages already in the merge request by using them as a default. **Scenario: drive by commit message** – todo **Scenario: detailed first commit message** – todo **Scenario: atomic committer, feature branch rebaser** – todo ### Vision Thoughtful commit messages are very helpful when reviewing code months or years after it was added. Although the conversation may be captured in an issue or merge request, the commit message should summarize the purpose of the change. We need to embrace the distributed nature of Git and make sure important information is stored in the Git so that forks and mirrors that no longer have access to the original GitLab instance or project do not lose access to valuable information. **Visibility of the squash commit message** – Although the merge commit message can be customized, the commit message of the squashed commit cannot. The title of the merge request is used for the commit, even if a better commit message existed in one of the commits that was squashed. **Default to detailed commit messages** – Automatically select the first long commit message to use as the squash commit message. This will provide an easy way for a developer to write a good commit message and know that this is the commit message that will survive the squash. Writing detailed commit messages as you go should be easier than writing non-descriptive commit messages. **Fix poor commit message before merging** – Previewing the squash commit message that will be used should highlight if an unhelpful commit message will be used but a way to resolve this should be provided. **Commit messages are part of code review** – We should treat commit messages as part of code review. See: https://gitlab.com/groups/gitlab-org/-/epics/286 ### Proposal TBD <details><summary>Previous proposal</summary> The scope for https://gitlab.com/gitlab-org/gitlab-ee/issues/150 didn't cover this, so at the moment a squashed commit takes its message from the title of the merge request. However, it would be nice to allow the user to pick the message for the squashed commit. For the two merge commit merge methods, we would then have two textboxes (one for the squash commit message, and one for the merge commit message), which might be confusing. For the fast-forward merge method, there is no merge commit, so this seems like an easier win. It would also be good to pick the author, where the MR author isn't sufficient: https://gitlab.com/gitlab-org/gitlab-ee/issues/1795 ### Design ##### Edit the squash commit in MR widget (New MR widget design from https://gitlab.com/gitlab-org/gitlab-ce/issues/25424#note_23180548) | 01 - `Squash commit` is checked, and then `Squash commit message` button appear. | |----------------------------------------------------------------------------------| |  | | 02 - Click `Squash commit message` button. `Merge request title` and `author` are the **default**. | |----------------------------------------------------------------------------------------------------| |  | | 03 - Choose the message from `Merge request title`, `Commits`, or you can edit it. | |------------------------------------------------------------------------------------| |  | | 04 - Choose the message from commits. | |---------------------------------------| |  | | 04 - Choose `Edit message`. Users can `insert all commit messages` to the textbox. | |------------------------------------------------------------------------------------| |  | </details>