After digging through the source for the attached zip, it appears the zip file allows all merge commits for all branches. There is a configuration page for the attached zip that allows you to define which users have direct push permission to each branch.

My code attached on 11/Jul/14 simply denies all direct pushes to develop, master or release branches without exception. It allows merge commits to those branches done via pull requests for all users.

The one shortcoming with both solutions is STASH-4837 is still a problem. To work around this, we must disable the plugin for the repo, make the fix, then re-enable the plugin. Either that, or create an "integration" branch, merge changes from the source branch into that, then create a pull request targeting the protected branch. It's clunky.

I know my code is ready to use - we use it daily. I'm unsure about the attached zip. For either one you must build the plugin from source. Since you must do that anyway, it's trivial to test out the plugin on a test instance of stash with pre-defined repositories containing dummy commits, branches, etc. You literally just type 'atlas-run' after building the plugin to launch this. You can test out both to figure out which one works for you.

The history for this issue is a little confusing. Is the plugin in the attachment ready for use? We want this feature in our stash repository but are unsure if the plugin here is ready.

Thanks!

Michael,

support of users/groups would help for the case you mention of merging from development to master where we do have a single person that merges to master after a QA check, but I would like any of the developers to be able to push non-conflicting merge changes from a development branch back to an integration branch

David, I created a feature request for this: https://mibexsoftware.atlassian.net/browse/PRP-3.

I think you are right that even though it is possible with our plug-in to to configure branches where pushes without pull requests are allowed (through Ant patterns), it might be handy to have this. I could think of the case where I use a gitflow based branch model and merge new features from own feature branches into "develop" through PR's, but then want to merge them manually without another PR into "master" - but "master" should still be protected from direct pushes otherwise.

Just as a remark: The plug-in also supports to define users (e.g., integration managers) where these checks are ignored. Would this help?

That is correct Michael.

Hi David,

This is currently not possible with our plug-in, as it would block these changes without a new pull request. Just to get you right: you want to allow changes being merged into certain branches in case they have already been part of an approved pull request before?

Thanks,
Michael from Mibex Software

Micahel:

How does your plug-in handle when you need to merge already reviewed changes, say to catch an integration branch up with changes in development? In our setup, we often have integration branches that subtask branches are merged to as part of a pull request, but then the integration branch will need changes from other issues (the development branch). In my own custom plug-in based on the example code, I've set up the hook to block merging directory to integration branches to make sure that all changes are going through a pull request first, but then the hook also blocks syncing code from development to the integration branch (which I don't want).

At first I thought I wanted what this issue was talking about but later realized that I wanted pull requests that automatically merge when a certain set of people approve them. If it's being automatically merged, it would be done by an auto-merge user and no permissions are required beyond what are already available in Stash. The Workzone plugin implements this system.

We at Mibex Software have released an add-on that might help here. It is called "Pull Request Please" (see https://marketplace.atlassian.com/1212503) and allows to either use specific references (e.g., "refs/heads/master") or Ant glob patterns (e.g., "tags/**") known from Stash's branch permissions screen to protect Git references from pushes without pull requests. This can also be ignored for certain Stash users (e.g., repo admins). And there is a nice ASCII art generator built-in for the hook messages shown to users.

Feedback is very welcome!

Michael from Mibex Software

Thanks, that got me what I needed for now. Would still be nice to have a plugin or something built into Stash that would be more configurable for each repository/project/installation. For instance, we want to prevent pushing to master, development, release/.* and integration/.*. I'm sure each company/team is a little different in what they need.