That is the default behavior for GitLab (src: protected_branches.html). I don't know when it became default, since a commit on July 22 implies the verbiage (on line 13 of the old version) was already there at that time.

I'm still on sameersbn/gitlab:8.14.0 and my master branches are all protected (and I've done nothing to set or change them).

I'm not saying this is not an issue. If you had previously unprotected all of your master branches, or the branches were created before this became the default mode in GitLab, then who knows.

If that's the case, then it's likely something for GitLab issues, not here, since I believe this docker image is not doing anything that specific to repos.

I upgraded as well from 8.14.0 to 8.14.1, and now I can't push to my protected branches that I could push to before. Getting error saying "remote: GitLab: You are not allowed to force push code to a protected branch on this project" even though I am not force pushing. But yeah, most likely this is an issue for GitLab.

Users belonging to the "Masters" list can push to the master branch. I think only the repo owner (since it is a per-repo setting) can change this, but perhaps other "Masters" can do it as well.

To find the list, within the repo pull down the "repo gear" (top-right corner, typically under the user avatar) and select "Members". Each member that has been granted access will be specifically listed as a "Master" (among "Guest", "Reporter", "Developer", and "Master"). If instead of "Members" you go to "Protected Branches", the level required to push can be set. "Merge" ops can be "Masters" or "Masters+Developers", while "Push" ops can be restricted to "Masters", "Master+Developers", or "No one".

Odd that the behavior appears to be have modified from what was there before. Are you certain it changed at exactly the transition from 8.14.0 to 8.14.1? (Not that your answer here will affect my ability to help, but it might be useful if/when you take it to GitLab Issues.)

Yes, the issue started immediately after upgrading to 8.14.1. I am the Owner on those repos and tried all combinations with no success. If I take off branch protection all is good. Given the actual error message (talking about force push) if GitLab somehow thinks I am force pushing then it is expected to reject it. But I am not force pushing, Tried it from different machines, different repos, same result.

I'm stumped, sorry. (And GitLab is a bit swamped, you may not get much from them.) I suggest going to GitLab Issues as well as posting to ServerFault and/or StackOverflow (for community response).

Yeah, I might do that thanks.

According to this comment the issue preventing regular push to protected branches may be caused by a change in behavior between Git versions.

Essentially, the output of a git command in a specific scenario apparently changed from empty to a non-empty string, causing GitLab to erroneously think that a regular push is forced push.

The commenter reverted the GitLab container's Git version from 2.11 to 1.9.1 and the issue disappeared.

I'm seeing this issue as well (rejected force push when performing a regular push). Let's hope it is resolved quickly upstream.

The defaults for protection has been like that for a long time, the problem we see is that we can't push to a branch which has protection even if it isn't a force-push.

I now see these errors after upgrading to 8.14:

https://gitlab.com/gitlab-org/gitlab-ce/issues/25301#note_19420235

Ahh didn't realise that was the default behaviour, but I guess this bug in git bought it to my attention. I'm not sure what implications downgrading git would have in the container. Its probably worth waiting for an upstream fix I'd say.

FYI, you can release a quick patch by installing an older version of git still available on the Ubuntu servers:

apt get install -y git=1:1.9.1-1ubuntu0.3 git-man=1:1.9.1-1ubuntu0.3

Seeing the same issue on the published 8.14.4 image still. Can't push to master even though it's a regular push (non-forced) and I'm a project "Master".

@jasl8r, is downgrading to 1.9.1 a safe workaround? GitLab says the minimal compatible Git version is 2.8.

I would recommend to downgrade to a version like 2.10.2 Currently I don't know where you can get from the ubuntu space. I look into it in the evening.

Note that I've gotten this to build, but have not yet deployed to see if it fixes the issue. For dumb reasons this will require me to build it a second time and the deploy it. Which will take a while. However I think it should address the issue.

@lyda, nice, thanks for going that route. Do you know if the client version of git (not within the GitLab environment) impacts the issue, or is it just the git that GitLab uses internally?

@lyda, looks like your temporary patch will be much needed, as the upstream fix may be taking a bit more work to accept. (But they do "confirm" the problem is the internal git-2.11, and downgrading to git-2.10.2 appears to temporarily fix the symptom.)

The upstream has fixed the issue on Gitlab 8.15. https://gitlab.com/gitlab-org/gitlab-ce/issues/25301

I think we could follow the upstream version to deal with this problem.

I updated gitlab to 8.15+ so for me this problem doesn't exist anymore. Can anyone upgrade his system and say if it works ?

@solidnerd, I just tested and the problem has been fixed by the upgrade to 8.15.0.

After update to 8.15.1, I confirm also that the issue is fixed.

I can also confirm that the issue is fixed after upgrading to 8.15.1

I can confirm that upgrading to 8.15.1 fixes the problem here as well.

There's another thread on the issue https://gitlab.com/gitlab-com/support-forum/issues/207

Fixes it for me, closing my PR.

Sorry I didn't get back sooner, the upgrade resolves the issue, thanks 👍