Bitbucket Server 6.7.0 adds a new "Commit summaries" setting to the "Merge strategies" tab, at both project and repository level, which allows configuring the number of summaries appended to the user-supplied message when a pull request is merged.
The value defaults to 20, which matches the existing functionality, but it can be configured to 0 to completely omit --log details when merging or squashing a pull request. (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.
Note that 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.)
Best regards,
Bryan Turner
Atlassian Bitbucket
Suggestion
Bitbucket Server 6.7.0 adds a new "Commit summaries" setting to the "Merge strategies" tab, at both project and repository level, which allows configuring the number of summaries appended to the user-supplied message when a pull request is merged.
The value defaults to 20, which matches the existing functionality, but it can be configured to 0 to completely omit --log details when merging or squashing a pull request. (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.
Note that 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.)
Best regards,
Bryan Turner
Atlassian Bitbucket