The tag protection as part of branch protection is documented here:
https://confluence.atlassian.com/stash/branch-permission-patterns-313461041.html
A refernce to this documentation should suffice for now, as it provides a valid workaround, which we already use successfully.

Hi xabierdavila,

I've linked to a related issue where we'll track the suggestion for better tag protection: STASH-3794.

In the meantime, it is already possible to protect tags by using a branch pattern match and explicitly entering a pattern using the full ref form, eg: refs/tags/foo-*

We'll get this fixed up in the documentation.

I'm disappointed this issue has been closed without fixing the tag deletion issue.
I'm using Stash 3.11.1 and still can delete tags via

git push origin :refs/tags/foo-1.2.3

Starting with Stash 3.10.0 branch permissions can now "Prevent branch deletion". This will prevent deleting the branch both in the Stash UI as well as via pushes.

I don't believe my plugin does that, but If I am not mistaken the plugin api would allow you to intercept that type of event.

@michael.rappazzo

I'm guessing your plugin also doesn't catch the stash merge delete issue I mentioned either?

My company found the stash permissions lacking, so I was tasked to write a plugin which has more fined grained permissions. I made it use a syntax similar to gitolite (with RW+CD for permissions, regex branch names, and then user or group association), and added some of my own features. It didn't really take too long, so I would recommend this approach until stash catches up. We have been quite satisfied with this approach. Unfortunately, I can't release the source code at this point because it is a private company resource.

Another month, another comment to keep this thing alive.

Our organization has lost two release branches as a result of "branch permissions" not actually preventing all the methods in which a user can delete a branch. We've installed the "Protect Branches" Plugin, the "Protect Branches with unmerged pull requests" hook and configured the built in branch permissions and yet there is still a way to delete branches via the UI. Please make the branch permissions do what they advertise.

it is bad that an user can delete the branches from UI even though STASH application has various level of permission inheritance and blocking an access at branch level, but just because of this issue, other features for restrictions is not worth.

Can STASH take this as a critical issue and develop a fix for this

Have you see this one? https://marketplace.atlassian.com/plugins/com.sarav.stash.hooks.protectbranches.ProtectBranches

Is there a plugin available in marketplace to restrict branch deletion but allows to create / push changes?

Hi @jhinch, do you have any update on your plugin? Is it this one?

https://bitbucket.org/atlassianlabs/stash-refchange-settings-plugin

Gitolite's reflog has been able to help with that kind of problem for a long time, provided you try to recover before the server's next GC (I wouldn't be surprised if GitHub has the right software on the backend to allow this too, but don't expose it on the frontend) – and if you have proper backups, then the GC isn't really an issue either. Careful what you read from Collabnet, as they are really keen to point out the problems you can possibly run into with Git to promote their SVN solution. Part of this problem was their reliance on GitHub.

That all said, because Stash isn't GitHub, it doesn't negate the need for something like this for Stash. Force pushes need to be recoverable, at least for some period of time. Even in the face of proper backups, which could require some fairly substantial time to fetch off tape and could still cost a day of work.

Collabnet (are we allowed to mention competitors?) have a blog entry on this. http://blogs.collab.net/teamforge/collabnet-git-history-protection-a-new-proof-why-it-is-badly-needed

exactly. The concept is to allow users to have read/write access to the branches, but not allow them to remove the remote reference if it matches a particular pattern. Here is a sample entry in our gitolite installation. perhaps if will shed light on what kinds of things we are talking about. we create groups @repository_name for r/w and @repository_name_ro for readonly. The '-' after the 'RW' entry simple prevents the deletion.

   repo repository_name
     RW  master              =  @repository_name
     RW  .+[_]int$ .+[_]rel$ bugfix =  @repository_name
     -   .+[_]int$ .+[_]rel$ bugfix =  @repository_name
     RW  integration         =  @repository_name
     RW  release             =  @repository_name
     -   master integration release = @repository_name
     RW  refs/tags/          =  @repository_name
     -   refs/tags/          =  @repository_name
     -   maintenance[0-9]*[_].+ .+[_]integration$ =  @repository_name
     -   20130401_rel        =  @repository_name
     -   20130401_ECC_rel        =  @repository_name
     -   20130531_rel        =  @repository_name
     -   20130603_rel        =  @repository_name
     RW+                     =  @repository_name @configmgmt
     R                       =  gitweb @cit_global_ro @cme_global @repository_name_ro

(EDIT: Added noformat block)

Thanks for the reply.

One comment/question: Gitolite has functionality you can turn on (or hack into a secondary update script) such that when there is a ref deletion, one of two things can happen: the ref can be moved to a backup namespace, so that the data underneath it is still held (so it won't be garbage collected), and/or the ref hash can be remembered so that prior to any garbage collection you can undo the deletion/force push.

Even if I don't have the ability to restrict force pushes/deletes separately from branch permissions, I would find it very comforting to know that such activity can be reverted (again, prior to garbage collection). Not saying that this would have to be UI driven so that it's done fully automatically on the server, but a way to know past destructive history in a repository log of some sort would be fantastic. (Unless it's already in a log?)

Hi Jeff,

The Branch Permission functionality allows general restriction of reading and/or writing of changes to branches or tags. If I understand correctly, your use case would be covered by this.

This particular request is about being able to separately limit the ability to delete a branch or tag, so even if someone can push changes to a branch, they wouldn't be able to delete it.

Can someone clarify the difference between what this issue is requesting and the branch permission functionality already in Stash?

Am I right in thinking that what is being asked for here is a way to further restrict what can be done to branches for those that have access to a branch even if normal branch access controls are being used? So, I am in the allow list for branch X, but the idea here is to ensure that even though I am in the access list, I still cannot force push a change without first manually getting the ability to do so (by removing the restriction proposed in this report)?

If so, I'm all for it. I'm in the putting-together-a-proposal phase of bringing Stash to my company, and right now we are using Perforce where codelines can be locked. The ability to enforce the flow that when a branch is finished or a tag is made it is immutable unless manually and purposefully tweaked is going to be rather important to selling Git/Stash as a replacement.

The use case for the JIRA team is very similar to the one described above by roy.lyons@cmegroup.com.

The problem with that solution is that it prevents the deletion of temporary branches. Right now we prevent deletion on the following patterns for branches:
^master$
^release$
^integration$
.*_int$
.*_rel$

The developers can go completely nuts with deletion of the rest. We at minimum enforce that formal builds be done on ^release$ or .*_rel$ to make sure that's where the code is... ^master$ is supposed to be where they merge a production release to...

There are also a couple of teams where we give targeted tag move/deletion capability based on a pattern. usually something like "CI_SUCCESS" or something. We have been toying with using a tag for triggering formal builds as well... and they would need to be able to move that tag.

Thanks,

Roy Lyons

From: "Jean Risse (JIRA)" <jira@atlassian.com<jira@atlassian.com>>
Date: Wednesday, July 3, 2013 7:58 AM
To: "Lyons, Roy" <Roy.Lyons@cmegroup.com<Roy.Lyons@cmegroup.com>>
Subject: [JIRA] (STASH-2507) Add permission to disable branch and tag deletion via git push

Jean Risse<https://jira.atlassian.com/secure/ViewProfile.jspa?name=jean.risse> edited a comment on [New Feature] STASH-2507<https://jira.atlassian.com/browse/STASH-2507>
Add permission to disable branch and tag deletion via git push<https://jira.atlassian.com/browse/STASH-2507>

Would the following be a work around until setting more granular permissions is available through Stash?

Solving the problem on Git level:

git config --system receive.denyNonFastforwards true
git config --system receive.denyDeletes true

I'd appreciate your comments.

The problem with that solution is that it prevents the deletion of temporary branches. Right now we prevent deletion on the following patterns for branches:
^master$
^release$
^integration$
.*_int$
.*_rel$

The developers can go completely nuts with deletion of the rest. We at minimum enforce that formal builds be done on ^release$ or .*_rel$ to make sure that's where the code is... ^master$ is supposed to be where they merge a production release to...

There are also a couple of teams where we give targeted tag move/deletion capability based on a pattern. usually something like "CI_SUCCESS" or something. We have been toying with using a tag for triggering formal builds as well... and they would need to be able to move that tag.

Thanks,

Roy Lyons

From: "Jean Risse (JIRA)" <jira@atlassian.com<jira@atlassian.com>>
Date: Wednesday, July 3, 2013 7:58 AM
To: "Lyons, Roy" <Roy.Lyons@cmegroup.com<Roy.Lyons@cmegroup.com>>
Subject: [JIRA] (STASH-2507) Add permission to disable branch and tag deletion via git push

Jean Risse<https://jira.atlassian.com/secure/ViewProfile.jspa?name=jean.risse> edited a comment on [New Feature] STASH-2507<https://jira.atlassian.com/browse/STASH-2507>
Add permission to disable branch and tag deletion via git push<https://jira.atlassian.com/browse/STASH-2507>

Would the following be a work around until setting more granular permissions is available through Stash?

Solving the problem on Git level:

git config --system receive.denyNonFastforwards true
git config --system receive.denyDeletes true

I'd appreciate your comments.

Would the following be a work around until setting more granular permissions is available through Stash?

Solving the problem on Git level:

git config --system receive.denyNonFastforwards true
git config --system receive.denyDeletes true

I'd appreciate your comments.

From STASH-2507:

We use feature branches that we would like to clean up after merging. At the same time we don't want to allow branch deletes on our canonical release/development branches. Ideally there would be an option in Stash to deny branch deletes based on a glob pattern.
I know there is an option to delete branches when merging a PR but we often use feature branches without PRs.

I think it's a bit dangerous how the defaults allow default contributors to perform non-fastforward pushes, considering that git as of 1.8 still pushes all branches by default.

I can imagine a scenario where a developer is working on his own personal branch, decides to rebase his branch against master, and accidentally calls 'git push -f' omitting his branch name. doh

Jason - great news about it possibly being in the marketplace so soon. I let our team know, so we will probably be getting an evaluation of Stash 2.0 going pretty soon...

My preference on behavior is to pattern based delete prevention of branches to allow teams to kill any task branch or experimental branch they want, allowing us to keep *_rel and *_int and master branches from being wiped.

I would also like to see admin capability to wipe all branches, even if it is admin through the gui. Perhaps a simple check to see if you are admin (whole instance admin, not just project admin) can be done in an early version of the selective locking.

If you are tracking this effort in a separate ticket, let me know and we can put feedback and such there instead.

Hi savviness,

Wow you're quick. I only started to code it this afternoon. This week is the Stash teams innovation week so hopefully I will ship the plugin by the end of the week to the plugin marketplace so you'll be able to use it then.

In terms allowing branches or tags to be deleted I think there are two options:

• Granting specific users permission to delete branches or tags
• Allow for branches or tags to be deleted through the UI (as these are less likely to be accidental)

This functionality probably won't be provided for the 1.0 release of the plugin.

Hi Jason,

I saw that you started the stash-prevent-deletion plugin, it looks great so far. Once complete, will there be any way to delete branches/tags if we decide we want to, outside of disabling the plugin's options?

The way we solve this with our current gitolite setup is by giving users two sets of ssh keys. They'll have their normal ssh key with deletions disabled, and also a superuser ssh key with deletions enabled. The normal key is used by default, but if someone wants to delete a branch they can run a script that will swap in the superuser ssh key, perform a requested git command, then switch back to the normal key once the command is complete. The most important part for us is that the deletions don't happen accidentally.

This functionality as of 2.0 can be implemented entirely as a plugin. In short it requires you to implement a PreReceiveHook check each change as to whether it is a deletion and rejecting the push if this is the case.

This is one of the things that is sort of required before we can move from gitolite to stash. We want to move to stash... but we have to prevent users from being able to remove release branches and release tags, without restricting their ability to write or create the branches.

The new change in 2.0 which allows for branch-level write permissions is good, and a giant step towards making stash viable.

Just saying that we might be converting to stash fairly shortly after this particular item is implemented...

Hi,

please remember, that a 'forced push' also deletes some commits. Therefore I like to set fine grained permissions for those, too.

Thanks,
Simon

Understood, Jesse. I've reopened this bug and will link it to be related to the other, rather than a duplicate.

Thanks for the request!

Thanks Seb,

The other bug seems to be focused on specialty branches, so I wasn't sure if this was covered there. This would be a new repository wide permission vs a branch specific one. Specialty branch permissions would also be an upgrade compared to existing git servers (afaik), whereas the git server we are using (gitolite) currently supports this, and it's something my team considers a 'must have' feature.

Hi Jesse,
Thanks for the report! I believe this is a duplicate of STASH-2481 and thus I am closing this issue as such.

If you believe I am incorrect, please reopen this issue.

Thanks,
Seb