### Description Currently it is possible to push branches from other remotes to a gitlab server. ``` pas@test:~$ git clone git@awe.some:bla/bla pas@test:~$ cd bla pas@test:~$ git remote add other git@some.where:hey/there pas@test:~$ git fetch --all # ... pas@test:~/bla$ git push origin other/master Counting objects: 107, done. Delta compression using up to 4 threads. Compressing objects: 100% (66/66), done. Writing objects: 100% (107/107), 2.11 MiB | 0 bytes/s, done. Total 107 (delta 52), reused 87 (delta 33) remote: Resolving deltas: 100% (52/52), completed with 8 local objects. To awe.some:bla/bla * [new branch] other/master -> other/master ``` But those are not visible on GitLab. As far as I can see that aspect was firmly closed as wontfix: https://github.com/gitlabhq/gitlabhq/issues/1171 ### Proposal So, the proposal is to prevent the aforementioned situation by rejecting receiving of git packs to branches that would be invisible. ### Links / references https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols - see uploading data, how git-receive-pack and send-pack communicates using full ref paths. ### Documentation blurb N/A the git receive pack rejection message should explain the problem, and/or link to this issue. #### Overview > What is it? It's a dumb-proofing feature. > Why should someone use this feature? It's a sort of semi-active protection, it'd signal that GitLab doesn't provide a UI for interacting with those rouge branches. > What is the underlying (business) problem? Git stores things under [.git/]refs/{heads, remotes}. Heads are local, remotes are not. But if someone writes git push other/master, and that matches refs/remotes/other/master instead of refs/heads/other/master, then the same thing will happen on the receiving side - because, I guess, under the hood git uses the full refspec. > How do you use this feature? It's passive, it'll just protect you from annoyance! #### Use cases > Who is this for? Provide one or more use cases. For people who are lazy and don't really know git. So .. programmers.. !? ### Feature checklist Make sure these are completed before closing the issue, with a link to the relevant commit. - [ ] [Feature assurance](https://about.gitlab.com/handbook/product/#feature-assurance) - [ ] Documentation - [ ] Added to [features.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml)