Allow force pushing to protected branch #10203

New Issue

GiteaMirror · 2025-11-02T09:00:57-06:00

GiteaMirror commented

2025-11-02 09:00:57 -06:00

Originally created by @timbze on GitHub (Feb 1, 2023).

Feature Description

At this point you can only force push when a branch is not protected.

Once a branch is protected, it can be limited like this:

no pushes
all with write access can push
only white-listed users can push

Under option 3 (next to "Whitelist deploy keys..."), I would like an additional check box: "Allow force pushing by whitelisted users"

Screenshots

No response

Originally created by @timbze on GitHub (Feb 1, 2023). ### Feature Description At this point you can only force push when a branch is not protected. Once a branch is protected, it can be limited like this: 1. no pushes 2. all with write access can push 3. only white-listed users can push Under option 3 (next to "Whitelist deploy keys..."), I would like an additional check box: "Allow force pushing by whitelisted users" ![image](https://user-images.githubusercontent.com/35117769/216176539-e967917b-fcab-4b9f-949f-c6ab28637e1a.png) ### Screenshots _No response_

GiteaMirror added the type/proposal proposal/accepted type/feature labels 2025-11-02 09:00:57 -06:00

GiteaMirror closed this issue

2025-11-02 09:00:57 -06:00

GiteaMirror commented

2025-11-02 09:00:58 -06:00

@henrygoodman commented on GitHub (Sep 19, 2023):

Bump, I have a workflow where I revert a squash commit if some CI tests fail, and I am unable to push normally (because the tip is behind the remote counterpart), and cannot force push due to branch protection.

Add a checkbox to also allow force push

@henrygoodman commented on GitHub (Sep 19, 2023): Bump, I have a workflow where I revert a squash commit if some CI tests fail, and I am unable to push normally (because the tip is behind the remote counterpart), and cannot force push due to branch protection. Add a checkbox to also allow force push

GiteaMirror commented

2025-11-02 09:00:58 -06:00

@henrygoodman commented on GitHub (Sep 20, 2023):

TY @lunny, would also just suggest (the original proposal could seem a bit ambiguous due to a differentiation between users and deploy keys) that whitelisted deploy keys should have access to force push, as well as whitelisted users (if this is a common workflow for CI, then it is likely people are using SSH/Deploy keys for their git creds)

gh ref:
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

@henrygoodman commented on GitHub (Sep 20, 2023): TY @lunny, would also just suggest (the original proposal could seem a bit ambiguous due to a differentiation between users and deploy keys) that whitelisted deploy keys should have access to force push, as well as whitelisted users (if this is a common workflow for CI, then it is likely people are using SSH/Deploy keys for their git creds) gh ref: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

GiteaMirror commented

2025-11-02 09:00:58 -06:00

@sebastian-sauer commented on GitHub (Oct 19, 2023):

Setting in gh:

@sebastian-sauer commented on GitHub (Oct 19, 2023): Setting in gh: ![image](https://github.com/go-gitea/gitea/assets/1135157/75472920-954b-49e8-b3c0-f022ff3ea2c4)

GiteaMirror commented

2025-11-02 09:00:58 -06:00

@sebastian-sauer commented on GitHub (Oct 19, 2023):

I'd like to implement this feature.

Some questions:

Easiest would be to just add a new option "allow force pushes". This would allow everyone with push access to force push, too.

Github allows to additionally specify the users/teams or Everyone.

What do you think - is a simple "Allow" enough or should we implement it like github?

@sebastian-sauer commented on GitHub (Oct 19, 2023): I'd like to implement this feature. Some questions: Easiest would be to just add a new option "allow force pushes". This would allow everyone with push access to force push, too. Github allows to additionally specify the users/teams or Everyone. ![image](https://github.com/go-gitea/gitea/assets/1135157/0a9af034-bc8d-49dc-9d9f-117b797c3659) What do you think - is a simple "Allow" enough or should we implement it like github?

GiteaMirror commented

2025-11-02 09:00:59 -06:00

@henrygoodman commented on GitHub (Nov 11, 2023):

Trying to pick this up since a bit stale, how about something like this?

I don't think it is enough to have a toggle to allow all whitelisted users to also force-push, as use cases of force-push usually require a subset of whitelisted users with push access. Thus, it makes more sense to specify force-push whitelisted users more distinctly (i.e. specify exactly which users can force-push, but also have the option to allow all whitelisted users to force-push)

I think the section should always be enabled, i.e. be toggleable (even if Push is disabled), as it just specifies who can force push given that set of users has push access (even if no users currently have push access).

Default option when toggled is Everyone
Everyone means every user with push access
Whitelisted force-pushing also requires the same user/team to be whitelisted for push access, but this is not enforced. Users will just get an error if they attempt to force push without also having normal push access.

@henrygoodman commented on GitHub (Nov 11, 2023): Trying to pick this up since a bit stale, how about something like this? I don't think it is enough to have a toggle to allow all whitelisted users to also force-push, as use cases of force-push usually require a subset of whitelisted users with push access. Thus, it makes more sense to specify force-push whitelisted users more distinctly (i.e. specify exactly which users can force-push, but also have the option to allow all whitelisted users to force-push) ![image](https://github.com/go-gitea/gitea/assets/79623665/7599b3ae-443f-4762-943b-2a7919b9f584) I think the section should always be enabled, i.e. be toggleable (even if Push is disabled), as it just specifies who can force push given that set of users has push access (even if no users currently have push access). - Default option when toggled is `Everyone` - `Everyone` means every user with push access - Whitelisted force-pushing also requires the same user/team to be whitelisted for push access, but this is not enforced. Users will just get an error if they attempt to force push without also having normal push access.

GiteaMirror commented

2025-11-02 09:00:59 -06:00

@henrygoodman commented on GitHub (Nov 15, 2023):

I'm just going to start implementing above and make any changes based on PR feedback 👍

@henrygoodman commented on GitHub (Nov 15, 2023): I'm just going to start implementing above and make any changes based on PR feedback 👍

GiteaMirror commented

2025-11-02 09:00:59 -06:00

@SoulSeekkor commented on GitHub (Nov 15, 2023):

Looking forward to this, I have to force push rarely but it's annoying to have to rename a rule to do it and rename it back after it's pushed every time.

@SoulSeekkor commented on GitHub (Nov 15, 2023): Looking forward to this, I have to force push rarely but it's annoying to have to rename a rule to do it and rename it back after it's pushed every time.

GiteaMirror commented

2025-11-02 09:00:59 -06:00

@henrygoodman commented on GitHub (Nov 16, 2023):

PR is raised now, note the UI isn't precisely what I originally had in mind, due to how the template handles the logic, and it was a lot easier to implement in a similar fashion to the Push section. Regardless, it should still function as expected

@henrygoodman commented on GitHub (Nov 16, 2023): PR is raised now, note the UI isn't _precisely_ what I originally had in mind, due to how the template handles the logic, and it was a lot easier to implement in a similar fashion to the `Push` section. Regardless, it should still function as expected

GiteaMirror commented

2025-11-02 09:00:59 -06:00

@Urth commented on GitHub (Feb 14, 2024):

The proposed change is the only way to have functional feature branches that enforce signed commits. I would love to see this fixed. (the signed commit requirement is exclusive to protected branches...)

@Urth commented on GitHub (Feb 14, 2024): The proposed change is the only way to have functional feature branches that enforce signed commits. I would love to see this fixed. (the signed commit requirement is exclusive to protected branches...)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10203