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' '[email protected]' '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'
7
  • 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. Dec 6, 2016 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, 2016 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.) Dec 6, 2016 at 22:14
  • @jjlin That would be my next step of action. I ask here first in case it is something obviously boneheaded on my part. Dec 6, 2016 at 22:18
  • @Willie Wong according to projects.cs.uaf.edu/redmine/projects/public/wiki/…, GIT_TRACE=1 makes git report to stderr "about alias expansion, built-in command execution and external command execution". So, what are those commands in this case? (there are other tracing options but they don't seem useful in this case). Dec 6, 2016 at 22:40

1 Answer 1

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.

1
  • Bug is still present in GitLab 8.14.4.
    – Mihai
    Jul 18, 2017 at 15:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .