Cannot perform initial push to master on new repository via SSH as owner when group not owned by root

Summary

The symptoms to this problem appear to be similar to #1236 (closed)

Note: I've replaced my domain with "myserver" in my output.

On a new repository under a new group that my non-root (promoted to admin status) user is the sole owner of, I perform the SSH clone steps detailed on the project landing page. When I attempt to do my first push, I get remote: GitLab: You are not allowed to push code to protected branches on this project. HTTPS seems to function properly.

It appeared at first to be a protected branch problem, however, my user has owner-level permissions. I may be wrong here about how git or Gitlab works, but as far as I know this is occurring before the master branch even exists.

My first attempt to solve this was to make master unprotected on the project, but attempting to access the protected branches page simply redirected me back to the repository landing page (presumably because there are no branches yet). This seems like a minor bug from my perspective, but I wouldn't object if someone said this is expected behavior.

Steps to reproduce

Create a non-root user.
Use root to promote them to Admin.
As non-root admin, create a new group with default settings.
Under the new group, create a new project with default settings.
Clone the repository using SSH.
Make a commit.
Attempt to push.

Expected behavior

$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 222 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@myserver:mygroup/myproject.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

Actual behavior

$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 222 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: GitLab: You are not allowed to push code to protected branches on this project.
To git@myserver:mygroup/myproject.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@myserver:mygroup/myproject.git'

Output of checks

Results of GitLab application Check

Checking GitLab Shell ...

GitLab Shell version >= 3.6.6 ? ... OK (3.6.6)
Repo base directory exists?
default... yes
Repo storage directories are symlinks?
default... no
Repo paths owned by git:git?
default... yes
Repo paths access is drwxrws---?
default... yes
hooks directories in repos are links: ...
8/2 ... ok
1/3 ... ok
1/4 ... repository is empty
5/5 ... ok
8/9 ... ok
8/10 ... ok
8/11 ... ok
5/12 ... ok
9/13 ... ok
10/14 ... ok
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
Send ping to redis server: OK
gitlab-shell self-check successful

Checking GitLab Shell ... Finished

Checking Sidekiq ...

Running? ... yes
Number of Sidekiq processes ... 1

Checking Sidekiq ... Finished

Checking Reply by email ...

Reply by email is disabled in config/gitlab.yml

Checking Reply by email ... Finished

Checking LDAP ...

LDAP is disabled in config/gitlab.yml

Checking LDAP ... Finished

Checking GitLab ...

Git configured with autocrlf=input? ... yes
Database config exists? ... yes
All migrations up? ... ^[[Byes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config outdated? ... no
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory setup correctly? ... skipped (no tmp uploads folder yet)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
projects have namespace: ...
8/2 ... yes
1/3 ... yes
1/4 ... yes
5/5 ... yes
8/9 ... yes
8/10 ... yes
8/11 ... yes
5/12 ... yes
9/13 ... yes
10/14 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.1.0 ? ... yes (2.3.1)
Your git bin path is "/opt/gitlab/embedded/bin/git"
Git version >= 2.7.3 ? ... yes (2.7.4)
Active users: 4

Checking GitLab ... Finished

Results of GitLab environment info

System information
System:         Ubuntu 16.04
Current User:   git
Using RVM:      no
Ruby Version:   2.3.1p112
Gem Version:    2.6.6
Bundler Version:1.13.5
Rake Version:   10.5.0
Sidekiq Version:4.2.1

GitLab information
Version:        8.13.3
Revision:       8d79ab3
Directory:      /opt/gitlab/embedded/service/gitlab-rails
DB Adapter:     postgresql
URL:            https://myserver
HTTP Clone URL: https://myserver/some-group/some-project.git
SSH Clone URL:  git@myserver:some-group/some-project.git
Using LDAP:     no
Using Omniauth: no

GitLab Shell
Version:        3.6.6
Repository storage paths:
- default:      /var/opt/gitlab/git-data/repositories
Hooks:          /opt/gitlab/embedded/service/gitlab-shell/hooks/
Git:            /opt/gitlab/embedded/bin/git

Misc notes and workarounds

Some possibly relevant details:

I am not experiencing any public key issues.
Pushing and pulling on repositories with an existing history works fine - this only occurs for the very first push.
My non-root user is owner of the group - I've tried adding the user as an explicit project master as well.
Creating new projects as the non-root user in a root-owned group works fine.
I had left the server running for a while, and Gitlab seemed to have consumed all of my memory when I got back (4Gigs). I hadn't tried creating a non-root owned group before that so who knows if it's related. I rebooted to see if more free memory would help, but the pushing problem was still present. It continues to rapidly consume memory (seems to be #12692 (moved)). Probably unrelated, but please fix that.
Running gitlab-ctl reconfigure and gitlab-ctl restart do not seem to affect the outcome.

I have found four individual workarounds to get over this hurdle, but they're sort of unintuitive.

Go into the Admin panel and set default branch protection to unprotected temporarily just to get that initial commit in.
Create a file in the repository via the web interface (like README) and pull the changes. If commits are already present in the local repository, merge the remote changes with --allow-unrelated-histories. Then push and it works without any changes to branch protection.
Always create groups as root.
Add root as a co-owner to the group.