@Bryan, OK, I understand. As I said, I have been known to be wrong in the past, so I don't assume I am always right

Eddy,

The long-term goal is certainly to expose more settings at project level, and potentially instance level, via the UI. But how we handle that configuration needs to be carefully designed to ensure it scales well and doesn't become unusable or cluttered, and that configuration applied at different levels interacts sensibly and is messaged clearly. Rather than let the perfect (exposure via the UI) be the enemy of the good (exposure via REST) and delivering neither, we decided to deliver what we could in the timetable we were on. Not only that, based on the demand we've seen for configuring other things via REST (consider BSERV-3644, for example), we're confident many administrators are going to want merge strategies to be configurable via REST even when they're also configurable via the UI.

Best regards,
Bryan Turner
Atlassian Bitbucket

@Bryan: Thanks for the answer. I think that having no UI for instance level setting makes sense. At project level it might make sense to have it the UI. For instance, I am and admin in a project at work, I might know to use REST, but a less technical project admin (e.g. project manager or a scrum master) might have difficulties.

Thanks or the clarification regarding PR level option, it makes things more clear for me.

Eddy,

Instance and project level settings are not currently exposed via the UI, but they can be retrieved and set via REST. (There are some misprints in the documentation that have since been fixed and will be updated when 4.9.1 is released. Setting the instance level configuration requires full ADMIN rights to the instance, and setting it at the project level requires PROJECT_ADMIN.) Settings at a more specific level (most to least: repository, project, instance) override and replace settings from less specific levels.

As for the pull request level option, BSERV-2810 was specifically about being able to select whether to squash or not at merge time. Such a repository might have, for example, ff-only and squash-ff-only enabled. That allows the merger to decide whether to squash or not for each pull request. If a repository's administrators want a "consistent policy" to be applied, then they just enable that strategy and users don't get to choose at merge time. We built the feature to be as flexible or as restrictive as the person or people administering a repository want it to be.

Best regards,
Bryan Turner
Atlassian Bitbucket

@Clément: I think the request was to:
1) have the option to choose which merge strategy to use
2) have the possibility to set a default strategy via the web interface at Stash instance level, at project level and at repository level.

From the links you provided it looks like there is a slight mismatch: the new release repository level and pull request level setting is possible, but I haven't seen anything documenting instance or project level setting. I am not saying it isn't implemented, that is Atlassian's job to confirm, I am only saying I don't see those parts.

Note: I find the pull reques level option very odd, I would expect a consistent policy to be always applied in a project or repository, but I find it very strange a project might opt for different merge strategies from one pull request to the next. But I have been known to make mistakes , so I misght be missing something.

Isn't that covered since Bitbucket 4.9 (released yesterday), cf. https://jira.atlassian.com/browse/BSERV-2810 / https://jira.atlassian.com/browse/BSERV-3092 and https://confluence.atlassian.com/bitbucketserver/checks-for-merging-pull-requests-776640039.html#Checksformergingpullrequests-strategies?

I would actually prefer to use the --no-ff so I can see the different feature branches. I hope this was not removed.

Is this setting accessible in the UI on Stash 3.6.1 or later, or can it be set only from the properties files by the admin?

Hi Myra, thanks for your response. While checking for white spaces I noticed that I was working with the wrong properties file (a leftover from previous stash installation). After adding the required changes to the correct file everything works fine.

Still I think it'd be much more convenient to have these settings in web UI

Igor, you might want to check for whitespace – see https://jira.atlassian.com/browse/STASH-4571