Proposal: Disable force push in repo settings

[kolaente]

(Not sure if there is an issue about this exact thing already)

It would be cool if one could make a repo setting to disable force pushing for everyone, or just certain members. This would be in addition the current "branch protection settings".
Currently it is only possible to forbid pushing completely, I think it would be great if Gitea could only forbid force pushes while still allowing normal pushes.

[lafriks]

Currently it does disable force pushes for protected branches, there is imho even no way to allow them once branch is protected

[lunny]

@lafriks I think @kolaente means we could have an option to only disallow force push to some branches.

[lafriks]

But if branch is protected in what configuration you can do force push currently?

[kolaente]

@lafriks If the branch is not protected, or the user is whitelisted to push. I want to be able to allow normal pushing, but prevent users from force pushing. Currently, if the branch is protected, the user is neither allowed to push normally.

[lafriks]

@kolaente but you can protect branch and whitelist team, this way users will be able to push but not force push

[jbeyerstedt]

I think, this is the same problem I have with the branch protection settings.
The text at the "Enable branch protection" checkbox says:

Prevent deletion and disable Git force pushing to the branch.

This is would be, what I expect to happen, when the checkbox is activated. No-one will be able to delete this branch and force pushing will also not be possible. But the issue is, that any kind of pushing is disabled (which is not, what the text says).

Then there is the "Enable push whitelist" button, which has the explanation:

Allow whitelisted users or teams to bypass push restrictions.

This does not clearly say, if the whitelist will only be allowed to push normally, or also be allowed to force push.

So the behaviour, that you want to have an option to disable force pushing, but keep "normal" pushes, is possible (by protecting the branch, but adding the users to the whitelist, as @lafriks stated). So the the real issue is, that explanation texts do not say, what really will happen.
(It you think, this is a separate issue, I will open another one)

[lafriks]

@jbeyerstedt descriptions definitely needs updating. Currently to my knowledge force pushes at disabled always. When no users is whitelisted puses are disabled completely except for PR merges

[jbeyerstedt]

As far as I have tested it, this is correct. If branch protection is enabled, no force pushes are possible. "Normal" pushes can be (re-)enabled with the whitelist.
This behaviour is fine as it is, so the only issue are the descriptions. Therefore the issue label "kind/proposal" is not quite accurate, but it's more likely a bug. (I haven't found a better suiting label)

[lunny]

@jbeyerstedt I think this issue is about add a method to only disable deletion and force push. So that we don't need to set push whitelist(currently you have to set who can push normal commits). I think it's a new issue, it's not the same as what you are talking with @lafriks. So I think it's not a bug but an enhancement.

[jbeyerstedt]

If I look back at the issue title, you are right, that this issue requests an additional, more easily accessible option to disable force pushing for the whole repo (with white- and blacklist).

But reading the description of this issue, it was not clear to me, if this really was the request, or just the result of being not able to find the existing functionality. That's the reason, I asked and tried to get to the bottom of the question. (You know, sometimes you ask something, because you think, that this will get you further down the road, but your real issue is something different).

[davidsvantesson]

I think this issue is somewhat similar to #8288 (but different parts of the branch protection settings). As I understand there is a wish to not have to enter a whitelist for pushing but everyone with write access would automatically be whitelisted.

[davidsvantesson]

Isn't this issue duplicate of #5731?