Can't set commit message with merge queue

[sethsamuel]

Beyond an annoyance, this means merge queues can't be used with any PR that had a [ci skip] commit anywhere on the branch, as it gets copied into the auto generated merge commit message.

[klimburg]

This is preventing our org from adopting the merge queue which is an otherwise great feature as we use squash and merge and this makes really awful commit messages without being able to reword them.

[jswang]

We also would really want a merge queue with the ability to reword the commit message. Pretty important feature for us, and gitlab supports this. We're looking into switching gitlab for this feature alone.

[philip-mourdjis-oxb]

Just to add another voice to the list of people / organisations asking for feature please 🥺
If it adds fuel to the fire we are also considering swapping to gitlab.

[amccabe-astronomer]

I was routed here after a filing a bug about not being able edit a commit message before adding a PR in a merge queue.

I hit precisely the issue Seth hit above with [skip ci] in one of multiple commits in a feature branch. This is not a cosmetic problem, it blocked our merge queue and release process while we had to troubleshoot the pipeline. Further, it's a regression from existing merge functionality.

[andyscott]

Our engineering team would also like to retain the "edit message" functionality when merging via merge queues.

[klimburg]

I found out there is a bit of a work around where you can now change the default commit message to just pull request title and number from this discussion on the merge queue public beta based on @willsmythe 's comment

#46757

[magicus]

That is great as a partial solution, but setting the commit message is still missing.

[spetrosi]

So what is the default commit message, why using merge queue? I do not understand the point of allowing users to manually re-write commit messages. We are running commitlint in a CI to ensure that each commit meets the conventional commits format. And I do not want GitHub to display a window where users can then re-write the approved by commitlint message into something else. This can lead to a message not meeting the format if users by mistake do some typo.

[dsinn]

I do not understand the point of allowing users to manually re-write commit messages.

As the opening thread stated, any PR with a [ci skip] skip commit on the source branch would cause the merge to be skip CI.

I have another use case. One of the repos I work on only allows "squash and merge" because of how active it is, and the "pull request title and number" as the default message workaround won't do. That prevents PR mergers from keeping context in the message and from cleaning up any commits that came from discussions on the PR that won't make any sense once the commits are squashed. The number alone in a commit message doesn't suffice because:

1. I need to browse the Git log multiple times a working day, and it would be slow and exhausting for me to have to copypaste a PR number into a new browser tab for every commit I see (since everything but the PR title would get removed).
2. Who knows if we'll ever switch to GitLab or another competitor?

I've never used commitlint as part of my workflow, and probably won't any time soon.

[GavinFrazar]

Our engineering team at Teleport would also like to have this feature.

As a workaround for my own PRs, once I'm ready to add the PR to the merge queue I squash my branch's commits myself and force push the branch.

A major disadvantage of this is that it triggers a pointless CI run, costing us more $$$ for GHA. I try to at least add [skip ci] to my busywork commits while addressing feedback to avoid extra runs when it makes sense.

Another disadvantage is that if I don't remember to squash things before merging, my merge commit can contain a bunch of busywork commits like "fix test", "address feedback from ...", etc. Same for my coworkers.

Merge queue is great, but I really miss being able to reword my commit message in github before squash/merge.

[willmurphyscode]

I would also really like to see this feature. In my opinion, one of the great things about setting a repo to "squash and merge" is I don't have to worry about what the commit messages and history look like in a branch that's being worked on -- I can just clean it up in one go at the end. Losing that is enough of a drawback I'll probably disable merge queue.

[thbar]

Our team at https://transport.data.gouv.fr is also quite annoyed by this. Any PR with [skip ci] at any point of the history, merged via a squash-merge (which is more readable on the main/master history) will block currently.

Either the ability to edit the message, or to only take [skip ci] in the latest push and not the full commit merge, would help.

We would like to save some CPU cycles on highly iterative branches.

[nbuckwalt]

The Contrast Security team providing our upvote on this request as well.

[lazyoracle]

Giving this some traction. The ability to reword and add a detailed commit message even when using the merge queue is important for us.

[OsamaSBCrea]

Just a funny observation here, this functionality is available through GH mobile app but not through web. It'd be nice to have it on web.

[magicus]

Is that really so? That's very surprising. If so, it must reasonably be supported by a GitHub API. It would be interesting to find out what API that is.

[OsamaSBCrea]

After trying it, the option is there but the edit is ignored once the PR is enqueued 🤦‍♂️

[magicus]

I see. It sounded too good to be true. But maybe this should be reported as a bug on the app?

[mark-pictor-csec]

Here's hoping this means the full feature is nearly ready, and one portion (mobile support) was accidentally enabled a little early.

[TTMichaelA]

If only! Over a year later and still not possible.

[jasonleenaylor]

Our FieldWorks project would be using merge queues if this was possible, additionally we would like to be able to put restriction rules in place on this message and also on squash and merge commit messages.

[florianliebig]

What is even more weird is that it seems to take the initial PR title. When you update your PR title and then add to merge queue it takes the first one

[TJackhammer]

Just to pile on, I would really like this feature. It is significantly degrading our repository's commit message quality.

[WillVanKeulen]

Our team would also very much appreciate this. The readability of the commit messages has gone way down since we adopted the merge queue over the individual squash and merge option. Devs are either forced to live with the excessive verbosity now being forced on us or must proactively combine individually meaningful commits that would otherwise be preserved in the PR for historical sake but do not need to be mentioned in the final commit message.

[opajonk]

Actually, this feature may be a show-stopper requirement for using conventional commits on main. We evaluate to use conventional commits so we can derive release notes etc. from git history already. However, to make the transition reality in an ongoing project, we have to use a GitHub Action that checks the message as part of the merge queue, and bumps out those PRs which do not meet the requirement.

Without being able to edit the commit message before sending the PR to the queue, this will be a lot harder...

[james-johnston-thumbtack]

This is also an issue for me. I generally take the time to write high quality multi-line commit messages that give high-level descriptions of the changes being made. A repo I contribute to recently switched to merge queues. Those commit messages now are being lost. The commit quality of this repo in general has subsequently decreased because all I see in the commit logs are 1-line commit messages with no further explanatory text in the commit message.

[zzJinux]

Please, GitHub! Readability of commit history is the most basic thing to account for, and the Merge Queue is undermining it...

[sri-cherukuri]

This is reason enough to never use merge queues. It can make the a repo's history nearly undecipherable and unsearchable from CLI

[joluizquierdo]

Same case here! We really need this feature in our ORG in order to apply conventional commit to our git history.

[dahlbyk]

Adding a related request: we should also be able to specify the author email address along with the commit message. As-is, Merge Queue commits always use the committer default address.

And/or implement https://github.com/orgs/community/discussions/4168.

[phantinuss]

This missing feature is also a show stopper for https://github.com/SigmaHQ/sigma to adapting merge queues.

[QuentinFchx]

Hi @ghostinhershell,
Gently bumping this discussion. It looks like this issue remains a common point of confusion for many in the community.
We would be very grateful for any clarification or guidance the team could provide.
Thank you!