5

It seems that my local installation of git (version 2.10.2) is such that whenever I issued git push, it is interpreted as git push -f. Is there a configuration variable that I could've set incorrectly to cause this behavior?

More background

Recently, the server I use upgraded their installation of GitLab (running community edition 8.14.2 b9442a5eb0, unfortunately, there's no easy way for me to find out what the previous version was). For every project that I own (and have master permission on), I get

[Tue Dec 06 02:21 PM] ArchDesktop $ git push 
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 765 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: GitLab: You are not allowed to force push code to a protected branch on this project.
To REDACTED
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'REDACTED'

I assume this is due to the implementation of "protected branches" in more recent versions of GitLab. Now, I should be able to push stuff, since I have Master access to my own projects. Furthermore, if it were just permission issues, the error message, I understand, should read

remote: GitLab: You are not allowed to force push code to a protected branch

with no mentions of force pushing. So the question really is: why is Git trying to force push my commits when I didn't tell it to?

Even more background

Once upon a time I read up on how Git works and actually understood it. Then I started using it and have largely forgotten. It is therefore entirely possible that I am doing something completely wrong and not understanding it. I am not even sure how to diagnose this problem. So any comments on what I need to include to this question or what obvious things I should check are welcome!

Additional Info

As requested: git config --list gives only (in addition to my name, email and the URL of the repo)

user.name=*******
user.email=******
push.default=simple
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
remote.origin.url=**************
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
branch.master.remote=origin
branch.master.merge=refs/heads/master

Slightly redacted output of GIT_TRACE=1 git push:

09:13:50.859273 git.c:349               trace: built-in: git 'push'
09:13:50.859524 run-command.c:336       trace: run_command: 'ssh' 'git@gitlab.REDACTED' 'git-receive-pack '\''REDACTED.git'\'''
09:13:54.097551 run-command.c:336       trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
09:13:54.098218 exec_cmd.c:120          trace: exec: 'git' 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
09:13:54.100884 git.c:349               trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress'
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 389 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: GitLab: You are not allowed to force push code to a protected branch on this project.
To REDACTED
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'REDACTED'
Improve this question
9
  • Silly question: Did you attempt a git pull prior to your git push and perhaps also have you unprotected master to see what happens? I agree that the error message is weird if you are not explicitly using git push -f? – Giacomo1968 Dec 6 '16 at 19:41
  • @JakeGould: for unprotected master it works as stated; so the issue really is with the branch being protected. git pull tells me it is already up to date. – Willie Wong Dec 6 '16 at 19:44
  • A more verbose output may reveal what git is doing under the hood. Anyway, git-scm.com/docs/git-config tells where the Git config files are. and stackoverflow.com/questions/12254076/show-git-config tells how to dump all effective options. – ivan_pozdeev Dec 6 '16 at 21:37
  • Force pushes are destructive and should be used only with caution, so I think it's pretty unlikely there would be any option that would regularly imply a force push. Have you contacted your GitLab admins? I'd guess the problem is most likely on their side. – jjlin Dec 6 '16 at 21:52
  • I'll include git config info in the question; I don't see anything immediately obvious though. If you can tell me how to make Git be more verbose I would also appreciate it. (Setting GIT_TRACE=1 doesn't give any useful info.) – Willie Wong Dec 6 '16 at 22:14
3

I contacted our friendly local GitLab administrator, and it turns out to be a known bug:

With GIT version 2.11.0 installed in combination with Gitlab v. 8.11.x - 8.14.2 Master or Developer are not able to push to protected branches even if they have the correct permissions.

Reading through the comments, it seems that the cause is already found (though I cannot make too much sense of it myself), and probably will be sorted out in a future release.

One of the things that the admin pointed out to me (which also explains why I didn't find this bug myself when I did the search), is that it is the git version on the server that matters. While I run 2.10.2 locally, it is the update to 2.11.0 on their server that caused the problem. So when I looked for specific conflicts between 2.10.2 and GitLab I didn't find any.

Improve this answer
1
  • Bug is still present in GitLab 8.14.4. – Mihai Jul 18 '17 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.