[Feature] Allow autodeleting branches after their PRs have been merged

[delvh]

• Gitea version (or commit ref): 1.14.0+dev-800-g752545023

Description

Most often, after a PR from branch a to branch b has been merged, a is not needed anymore.
It would be nice (and time/ energy saving) if you could activate in the repo settings whether branches of merged PRs should be autodeleted (as humans tend to forget to delete the branch after it has been merged, leading to unused branches in the project).

Later on, even the distinction between merged and closed PRs could be made by using another setting whether branches of closed PRs should also be autodeleted (even though that will be used rarely).

[lunny]

So this could be a personal setting.

[delvh]

No, not really:
What is the behavior when person a commits and is basically the author of the PR, and he does not activate autodeleting branches, while person b merges the PR and has autodeletion active?
Will the branch get closed or not? Should Person B be responsible then for the deletion of the branch?

While it might be a little bit more work on the user side to check the box for each repository, it definitely leads to way less confusion and a unified solution for all PRs getting merged, instead of a per person behavior. And less confusion also means less unnecessary bug reports being filed.

[tomaswarynyca]

I agree with @delvh it has to be a repository option.

[lunny]

For the original repository or fork repositories? I assume not for original repositories, because original repositories' setting should not delete fork repositories' branches there is a permission problem here.

[jolheiser]

One of the (only) things Azure does that I like is, when closing a PR, it gives me a checkbox for whether to remove the branch.

The checkbox could perhaps be defaulted to some user/repo setting, but then the checkbox can be changed ad-hoc.

Obviously this would need to adhere to branch protection and other permissions

[delvh]

@lunny Can't forked repositories change the fork repo settings? I would have thought so…

[jpraet]

see also #13568

[techknowlogick]

closing as dupe of #13568