Thanks Bryan. I understand the complexities too, now. We'll continue to use --amend for now, I think. Or perhaps set summaries to 0 and then generate the commit log on the CLI and paste it in. Something like that.

Understood, thanks for the explanation, Bryan.  I'll set the commit summaries to 0 as suggested, and go from there.

Yes, KevinLentin's final paragraph, and my final paragraph, are saying the same thing. Please put the commit summaries into the merge dialog box as part of the suggested/default commit message, so that they can be human-modified.

@Bryan Turner - I think you've misunderstood the request. Your response seems to indicate you think I'm asking for automation of some kind. No. I just want to be able to edit the message. That's it. Bitbucket creates a squash commit message containing every date/author/commit-id/comment of every commit in the merge. That's cool. Just pop it into an edit box and let me adjust it before commit. I just want to trim things down a bit, remove useless commit messages (fixed typo, "merged master into feature", etc) so the commit message simply contains the work that's in it. As a completely manual task. The process is subjective anyway.

My current flow is this:

• PR
• Merge using squash in Bitbucket UI
• git checkout master
• git pull --prune
• git commit --amend
• Go through and clean up the commit message, reduce it from 100 lines to 10
• git push --force

And just hope you get it done quickly enough that nobody else pushes before your --force. That's just silly.

All we need is to be able to edit the message before the commit gets made. Maybe add a "edit commit message before merge" checkbox to the merge screen.

Or, perhaps stated differently: Add the commit summaries to the message BEFORE you present it on the PR merge screen shown in the attachment. Currently we can edit the heading before bb adds the commit summaries. I want to edit the commit summaries.

I came looking for a way to edit the default message that bitbucket inserts when we merge a PR with the "squash, ff-only" strategy. I don't like the message they insert in there which says "merge pull request #xxx branch this to branch that", followed by a bunch of newlines and older commit messages. it's ugly.

I came across this ticket, and I felt like you were requesting the same thing I was looking for: I want to type a new commit message which summarizes, in my own words, what this whole squashed clump of commits is doing.

The conversation between you and Atlassian left me with the impression you didn't understand each other.

I then discovered, in continued googling, that the default message that bitbucket inserts IS EDITABLE. I just have to click on the words next to my face, and type a new message in. The OP's screenshot kind of shows that–he has clicked in the field since I see the text insertion point, but he hasn't erased his default message (yet).

The whole mess of newlines and commit messages from the many-commits-before-the-squash aren't visible here, but they do get added to the commit log, UNLESS YOU TURN THAT OFF. By turning off that part, you will have full control over your commit message--just the words you type manually in this dialog, prior to hitting Merge.

You can TURN OFF those many-commits-before-the-squash messages in your project settings, on the MergeStrategies page, in the "Commit Summaries" section at the bottom--just set it to 0. At that point, you'll have just your freshly-typed, new squash commit summary message, and none of the 10 pages of prior commit IDS, committers and dates.

That's good enough for me.  But oh, I do see that you're wanting to visually see and maybe modify those prior commits. That would be easy for Atlassian to do:  Just take the "20" (or however many 'Commit Summaries' are configured) commit comments, and throw them into that text field at the top, so we can hand edit THE ENTIRE THING. The issue with the way Atlassian implemented it, is they append the "20" commit summaries to whatever you type in the dialog box. It would be better if they just included those summaries IN the text field in the box.

kevin.lentin1115569628,

In the spirit of openness and to try and set realistic expectations, I suspect there's not much chance the system ever offers that sort of functionality.

• Merging without showing a dialog isn't something the system should offer; the merger should always get a chance to review those details to ensure they're targeting the correct branch, see any auto-merge they might trigger, confirm whether they want the merged branch deleted, etc., before the merge runs. The dialog gives the user a chance to back out and change their mind.
• The sort of changes to the squash message you're describing might be scriptable (the more incidentals you throw in, like "perhaps remove the occasional 'updated node_modules'" and "maybe I might keep one author", the less likely it is the work could be done in an automated way without "mistakes"), but are not sufficiently generic for it to be something the system includes.
• "Or maybe I might keep one author. Because if I'm merging, I want the code author credited." BSERV-4415 seems like a better solution for this than an "Author:" line in the commit message, and is more likely to be what we implement.

BSERV-10559 is about making some sort of configurable pattern to allow administrators to configure the things they want to include in the merge message and control, at least at a basic level, how they should be structured, but it's unlikely, as part of building that, that we'll include the sort of text transforms you're describing here.

Best regards,
Bryan Turner
Atlassian Bitbucket

What I want is the ability to edit the squash commit message. We do a PR merge, there is no dialog. It just merges. And we get a commit message with lists of commit IDs, and commiters and dates, etc. It's pages long. What I want to include is the individual comments on the commits. Roll it up, perhaps remove the occasional "updated node_modules". Sure, we could set summaries to zero but then I don't know what they are. I effectively want to take the full squash commentary and delete any blank line, any line starting with commit, Author: or Date:. Or maybe I might keep one author. Because if I'm merging, I want the code author credited. 

nclark1,

I'm not sure what you're looking for. If the --log messages are a problem for your team, the functionality has been available for ~8 months now to turn them off. With that done, whatever message you put in the dialog is verbatim what is applied to a squash "merge". So the ability to edit the "full commit message" has been available since Bitbucket Server 6.7 was released in September 2019. None of the "Bitbucket competitors" that I'm aware of use --log, so simply setting commit summaries to zero achieves the same end behavior as they have, as far as I'm aware.

Best regards,
Bryan Turner
Atlassian Bitbucket

What's really great about this is that it effectively makes Bitbucket's squash-merging useless if you care about what goes into the squash commit message.

I'm legit surprised that the dev crew isn't more interested in implementing this feature, which has been asked for by so many people  - across a whole pile of duplicate support tickets. This issue has over a hundred votes and 200 watchers on this ticket alone.

It should be a basic UI affordance for anybody who's trying to squash-merge, and it's one provided by every Bitbucket competitor that I know about.

e0d9322d42d1, caner.arda4,

Apologies for not responding; it fell off my radar. As 8736a1ce60b4 indicated, yes, this shipped in 6.7. It's now possible to configure the number of commit summaries to append to merge/squash messages for pull requests, and when that is set to 0 you effectively completely control the merge message with whatever you enter on the dialog.

Just to reiterate one point, though, as I explained previously (5 Sep 2019, comment above), if >0 commit summaries are enabled, they still do not appear in the message textbox, and will still be appended to whatever message is entered in the textbox. At this time, we don't have any plans to try and include the summaries that will be used in the textbox. For teams that require full control over the message, most likely they don't actually want any summaries anyway. It's a more complicated change than "Just show the summaries, lol", since some teams may wish to make them required and some teams will not. For now, our belief is the existing functionality should work for most teams (and for the teams where it doesn't, they probably really want BSERV-10559).

Best regards,
Bryan Turner
Atlassian Bitbucket

I believe it was. This is from the 6.7 release notes:

• More control over commit messages – Set the number of commit summaries included in the commit message when you merge a pull request. The Pull request merge strategiespage shows you how.

We upgraded to 6.10 recently from 5.something and have this feature available to us.

bturner, 

Has then been released with 6.7?

Hey @BryanTurner, is it already released? I don't see BSERV-8384 in any of Bitbucket Server release notes starting from 6.7: 
https://confluence.atlassian.com/bitbucketserver/bitbucket-server-6-7-release-notes-976757805.html

Are you giving any consideration to allowing us to change the template for the commit message header, i.e. the 'Merge pull request #xxxx in <repo> from <branch> to master'.

Being able to edit the message per PR is great, but it'd also be very useful to be able to push a different template so that everyone still follows the same standard for their merge commit messages.

Edit: Ah, just noticed this is already covered by this: https://jira.atlassian.com/browse/BSERV-10559

nicholas.clark,

If the max commit summaries is set to 0, whatever message is in the textbox is what will be used, verbatim. In that mode, then, you're editing the "final commit message," as requested. If summaries are not set to 0, however, they will still not be rendered and will be appended to whatever message is provided. At this point it is not on the product roadmap, or on my own personal after-hours agenda, to try and change that.

Putting the configured number of summaries into the textbox and allowing them to be edited/removed is a little more tricky than "Just do it". Aside from the implementation details (the current default message can be generated entirely client side, but including the summaries would require a server call), if an administrator configures that they want 5 summaries, but we put them into the textbox and the merger can delete them, then administrators effectively have no more control over the setting than they would if we just put the number field directly on the merge dialog. It's still not an enforced setting. For many organizations, that would probably be fine--but for others, it may be a problem.

At the moment, my thought is to let this new change simmer (it's likely to take many organizations a fair while to upgrade to 6.7+ and get it, especially given 6.7 isn't even released yet), and see what people think after they've had some experience with it. Then we can base next steps on "active" feedback--as in, feedback after use; I really appreciate the time and effort you, and others, have put into offering feedback to get us to this point, but there's a certain amount of theorycrafting involved at this point. After you've upgraded to a version with the ability to just turn the --log behavior off, you may decide that it really doesn't matter whether it's on the dialog or not.

Best regards,
Bryan Turner
Atlassian Bitbucket

@Bryan Awesome! Thanks for picking this back up. Will we be able to edit the final commit message after it's generated as per the reporter's original ask? It would be fantastic for the --log output to make its way into an editable text-box somewhere before the commit is applied.

A great workflow would be:
1. Project has the new setting to control how many entries come out from the --log
2. Commit message gets auto-generated
3. I can edit the full result, so that I can remove/change stuff in the message or add human details. Or I could leave it as is, pre-populated with the message that got auto-generated.
4. I hit MERGE and the squash is live!

For those who are looking for a way to eliminate the --log output when merging (or squashing) a pull request, Bitbucket Server 6.7 will include the following new setting on the "Merge Strategies" tab (in both project and repository settings):

(The wording is still subject to change, but the functionality itself has been merged and will be included in the 6.7.0 release.)

The setting defaults to 20 (the existing behavior), but can be set to 0 to completely eliminate --log output for merges and squashes. (Note that "ff-only" and "rebase + merge -ff-only" strategies don't use user-provided commit messages at all, so they already didn't, and still don't, append --log output regardless of this new setting.) The setting cannot be overridden at merge time. Administrators (project, repository or global) can configure the value they want to be used, and it will be used for all pull requests merged from that point forward.

When a value is configured at project level, if any repositories inside that project are configured to use custom settings rather than inheriting their settings, whatever commit summary count is configured for the repository will override whatever value was set at the project level. (This is the same handling that's applied to the enabled merge strategies; the most specific configuration is the configuration that gets used.)

On a different note, I apologize if the previous partial solution to this issue (granting control over the subject without the ability to control the appended summaries) caused people grief. Hopefully this new change, paired with that one, is closer to what people were expecting.

Best regards,
Bryan Turner
Atlassian Bitbucket

@Bryan Turner

Thanks for your help on this.  What setting is this configurable 256k you speak of?  Is it possible to set it to zero to make no commits ever append to the message?  That functionality plus the subject line editing you provided is really all I'm looking for.  

@Bryan Turner

Thank you for that heroic effort.  Much appreciated!

joo.lee

BSERV-10559 was split from this issue to tackle offering more complete control over pull request merge messages. I'll note that I'm not a PM, so I can't speak to when it will be roadmapped or ship. I implemented the ability to control the message subject on my own time, off roadmap, because I felt like it would be useful to many, and it was a much simpler change to get over the line and shipped than full control over the merge message.

Best regards,
Bryan Turner

@Bryan Turner

That's my bad!  I'm working off of 5.3, so looks like upgrading should take care of some of this stuff.

Being able to change the subject line makes the merge-squash so much more usable.  

Do you guys have a separate ticket open for editing the full body of the message as well?

In an my ideal world, merger would be able to simply take the PR subject + body & use that as commit message by default.

Thanks for the quick turnaround on this

joo.lee,

You can change the subject line of a squash merge, and this issue is marked resolved... You've been able to do so since Bitbucket Server 5.8. At present, the only thing you can't do is control whether a synopsis of the squashed commits gets included in the final message.

Notice that the subject line is now inside the textbox. It's defaulted to the same subject the system has always used, but you can delete that line and change it to whatever you'd like it to be. (If you delete the subject and don't enter anything in the textbox, the system will automatically default the subject back to the standard one.) The message from the textbox is used verbatim for the subject and the beginning of the body. If you create a merge commit, a shortlog of the first 20 merged commits is appended to the message. For squash merges, details about the first up-to-20 squashed commits are included, unless the resulting commit message becomes "too long" (a configurable value, 256K by default), and then fewer commits are appended. (If the user-entered message exceeds 256K, then no commits are appended for squash merges; normal merges always append 20.)

Are you perhaps running an older version of Bitbucket Server which simply doesn't have the feature? Because if what you're looking for is the ability to change the subject line, that shipped over a year ago.

Best regards,
Bryan Turner

Edit: I should note that there was a race condition issue in the UI which meant, in certain cases, the UI did not send the user-entered message to the server when "Merge" was clicked, resulting in a default message even though a custom one had been entered. That was tracked on BSERV-10744, and fixed by the same changes that addressed BSERV-10817.

This has been open for almost 3 years and yet still not resolved.

I'd say the lack of being able to change the subject line on squash merge goes directly against the spirit of squash merge. 

What'd it take to get this issue bumped in priority?

I like having the previous squashed commit messages included, FYI...

The last line of comment-1763926 reads:

it appears I may have mis-read your comment. You're saying the prefix isn't allowing customization, and I think I may have a reproduction of that issue. I'll update again shortly as I continue to investigate more deeply.

it seems this issue has slipped of Bryan's radar and should be re-opened.

We upgraded to 5.8.3, only to discover this issue – as described – has not been resolved.

It is still impossible to avoid "polluted commit logs on master", and "what should be a 1 click operation" is still "a more laborious and error prone process".

It is very disappointing, after being advised that a problem that affects the productivity of one's team every day has been fixed, to have to go back to square 1 and vote for some other unrelated issue, in order to get the actual issue fixed.

daniel1877929954,

To be clear, it's working exactly how I said it would when I closed the issue:

The --log output showing which commits were merged will still be appended, and is not configurable. The change here makes the subject of the merge commit editable, but it's still not exactly the "full" message. From the majority of the comments on this issue, this change appears to address the primary request.

git merge --squash, produces a SQUASH_MSG file detailing the squashed commits, which we append to the end of the user-provided message because it's providing the equivalent of the --log information that a "normal" merge would produce. My apologies for any lack of clarity, but it's working as intended.

(I'll note that in the single commit case, squashes are handled differently at the Git level, which is why you're seeing it appear to work when squashing a single commit.)

For total control over the message, including the ability to suppress --log and SQUASH_MSG, you'll want to vote for something like BSERV-10559.

Best regards,
Bryan Turner
Atlassian Bitbucket

Edit: Pardon, it appears I may have mis-read your comment. You're saying the prefix isn't allowing customization, and I think I may have a reproduction of that issue. I'll update again shortly as I continue to investigate more deeply.

Hi daniel1877929954, could you please raise a support request so we can dig into this? Thanks!

This does not appear to work for a Squash merge where there are multiple commits to squash. The log message in git is still "Merge pull request #X in..." and the edited message does not appear to have been used anywhere.

It does work for a "squashing" a single commit.

Starting in 5.8.0, the leading "Merge pull request..." portion of the commit message is now included in the edit box, and can be deleted/replaced. By default the edit box will be collapsed to a single line and will contain the subject which the system has used in all previous releases. Clicking into the edit box will expand it and allow change the subject. The edit box has some highlighting rules applied to help call out what part of the message will be used as the subject and what will be the body. The expanded box looks like this:

The --log output showing which commits were merged will still be appended, and is not configurable. The change here makes the subject of the merge commit editable, but it's still not exactly the "full" message. From the majority of the comments on this issue, this change appears to address the primary request.

I have separated out BSERV-10559 to track a "richer" pattern-based approach which would effectively allow configuring whether to use --log in addition to the rest of how the message is constructed. In the spirit of openness; I'll note that it's a low priority feature request and it's uncertain when/if it will be delivered. User votes and, even better, explicit, rationally-provided use cases will help determine how PM prioritizes that further improvement on the roadmap.

This change extends to the Java and REST APIs as well, and those changes were introduced in 5.7. Starting in 5.7, when merging a pull request via REST, the POST body (JSON) may include a "autoSubject":false property to to disable inserting the automatic subject (starting in 5.8, the UI always sets this to false as part of the merge dialog changes shown above). If a "message" property is not also provided, the auto-generated subject will be used regardless of the autoSubject property, because merge commits are required to have a message. Also, note that, if you've been setting the version to merge using the ?version query parameter, you should move that into the POST body as well:

{
    "autoSubject":false,
    "message":"A succinct and salient subject.

Some further details about the pull request that make the message even more useful.",
    "version":5
}

Similarly, PullRequestMergeRequest.Builder has a new autoSubject(boolean) which can be used to disable automatic subject generation when merging. As with the REST API, if a message is not set the auto-generated message will still be used.

Best regards,
Bryan Turner
Atlassian Bitbucket

We changed our process to commit manually, and push the results to the server. We script this...

git merge --squash <FEATURE_BRANCH>
git commit -m "Useful Message"
git branch --force <FEATURE_BRANCH> HEAD # These two lines mark Pull Request as remotely merged
git push --force origin <FEATURE_BRANCH>     # These two lines mark Pull Request as remotely merged
git push origin master

+1 This is a really annoying issue.  
All of our pull requests get squashed so every single commit message just says

"Merge Pull Request #123 in PROJECT from BRANCH to master"

Making the history very difficult to understand.

Without good commit titles history becomes useless. 

+1

Github does this really nice. Provide the title a link to the PR in the commit. Any details required can be viewed from the link. Why can't BB be similar. You should take ideas from your competitors.   Atleast allow us to configure it this way, if not doing this by default.

Right now the commit log is totally pointless if we are having a "squash" commit workflow.

@rbarnes **Instead of being auxiliary input to the default message, input should contain default Bitbucket's merge/squash message.

So user can decide whether to keep default generated message, replace it with his own or mix them both in any way.

And I like @John Heffner idea to put PR title and description in that message as default value (editable) for squash commit

johnwheffner525209792, I agree there's a case for templates or similar here. What might be a huge improvement for you is quite different to what others have asked for, so we need to pick through the use cases and balance simplicity and flexibility.

It would be great to have a configurable commit message based on a template, and also to let users edit at merge time in the UI.  But a simple, huge improvement would be for the commit message to come by default from the pull request title (first line) and description (body).  Information about the pull request id, etc., should appear below – at least not in the title line.

@jm you vote by clicking the link next to votes on the upper right under people

OK, how do I get the user mentions to work?

Our usecase is that our git master is synchronized with svn repo, which is the official repo. And of course, svn has some rules about the format of the commit message… 

So each time i merge a pull request (using a merge commit to preserve history), i have to rewrite manually the commit message of the merge commit prior to the sync with SVN. And that's just annoying…

Can I also add my vote please?  We have just spun up a new project with a new client where BitBucket is used and I am finding it very frustrating that I have to manually squash merge pull requests to get a useful commit message (with respect to viewing one line history).  I have sold my client on having a nice clean, linear history on master but this issue is making it more difficult than it need be!

Thanks thomas.v.judkins for the insight. The merge commit message allows manipulation of much of the commit message, just not the first line, so it sounds like there would be a way to switch, with some hopefully minor differences to what people are used to. It would be interesting to explore how well combining your "deliver" script and a pull request flow would work. It may be more work, but shifting more of it into BItbucket by way of add-ons could centralise everthing that "deliver" does now with more alignment to pull request flows.

Anyway, this is still something we're considering for prioritisation, thanks all for your input!

We also need this feature desperately. Without it, you either deny yourself the convenience of using "merge" button or use this button and make commit history on develop branch unreadable.

@Roger Barnes, I am not sure how much it is really incompatible, it just isn't simple to switch, and we will probably not use the pull-request merges. We typically 'deliver' our software with a script called deliver. It checks some pre-conditions, prompts the user to select which of their Version One stories they are delivering, and assembles a squash commit message 'header' with the V1 story ID, and user provided comment. The commit message 'body' contains additional lines containing generic squash merge message, and on-line git-log messages for each individual commit. We currently do not check build success/failure before delivering, but I was looking into having Bitbucket enforce some of those rules for us in addition to your "no open tasks", and "Minimum approvals" checks.

Basically, I was hoping we could tie your merge button into our existing script, and it sounds like that is not possible with the current software. It also sounds like it is not possible to have the Bitbucket merge button build a custom commit message, or tie into Version One.

thomas.v.judkins, could you elaborate on how the current behaviour is incompatible with your workflow? Feel free to email me rbarnes (at atlassian com) if you'd prefer not to discuss on this open forum.

It took me a couple hours of investigation to even find this page, and realize that tweaking the merge commit message is not possible. We have written our own script to perform merge checks and perform the merge for us. It would be nice to simply tie that script to the merge button, but the options above would work as well. After working with gitolite for years, I have been having some growing pains with having do everything in a special way for Bitbucket. It certainly is not a portable solution, and I am having a hard time replicating the features we had with gitolite. I am very tempted to just edit the repositories directly on the bitBucket server, and remove all the customization bitbucket provides.

Couldn't have put it better, Jeffrey.

I think this is a really basic feature and I can't understand why it's taking so long to be implemented. Currently the commit messages get so polluted it makes them completely useless. You just simply can't use git squash in this way in a professional setting.

If the total absence of the pull-request-accounting noise would really cause a big problem for other Atlassian workflows, could you at least provide a configuration option to make those details appear at the end of the commit, instead of the beginning? Replacing a developer's carefully crafted one-line title with this low-information-density title makes git log --oneline useless, which I suspect is the main problem people have in practice with the insert-only approach for merge commit message text today.

That would still leave the problem of a bunch of "oops, fixed X from review, now I fixed Y I just noticed" noise that most developers pride themselves on avoiding on mainline branches; ideally we'd also be able to delete all that unwanted text, too.

Hi Roger,

thank you for your detailed answer. I really appreciate it.

Regarding the expected impact, I cannot imagine how this could impact existing customers if the current message remains the same by default and editing/changing is optional. However, I trust your judgement.

Thanks,
Stanislav

Hi st.toshev1715703656, 

Unfortunately we are unable to divert a great deal of attention from all the things we are working on to comment on all of the suggestions we get on an ongoing basis. We do provide regular updates on the top 50 open suggestions by votes, a list that this suggestion is just shy of. 

The suggestion to allow editing of the whole commit message is a good one, but it is not as trivial to implement as it may appear, due to potential side effects for teams who rely on the way it works now. We are reasonably confident that we can change it, but want to ensure, in accordance with our values, that we "don't f!@# the customer". Validating the potential impact will take a little time.

If you would like to know more about how Atlassian Product Management uses customer input during the planning process, please see this post on Atlassian Answers and our new features policy. Thanks for your patience and we hope you appreciate our open approach to feature requests, even if we can't go into great detail with updates on each one.

• Roger

It is very disappointing that something that should be pretty simple to implement has not been resolved for an year now. And nobody from Atlassian has even bothered to comment on it.

If you don't plan to fix it, at least let us know.

Hi,

is there any chance that this gets prioritized and possibly scheduled for next releases any time soon? Or to provide a patch?

It breaks our JIRA/CI workflow too.

As per my question on Answers https://answers.atlassian.com/questions/43719791/answers/43726651, not being able to edit the merge commit message breaks our JIRA workflow for transitioning issues.